Status Codes (and OS/2 error codes)
Christopher R. Hertel
crh at ubiqx.mn.org
Fri Jul 12 14:22:33 GMT 2002
On Thu, Jul 11, 2002 at 03:01:34PM -0500, Steven French wrote:
> OS/2 had 16 bit errors - basically the ERRdos range (SMB error class) is
> mostly error codes introduced in OS/2 development and could be just as
> easily named "ERRos2"
The old X/Open doc says (in its description of availabel dialects):
"MICROSOFT NETWORKS 3.0 and LANMAN 1.0 specify the same SMB protocol
dialect. MICROSOFT NETWORKS 3.0 is used by DOS SMB redirectors and
LANMAN 1.0 is used by OS/2 SMB redirectors."
The SNIA doc says similar things about DOS LM1.2X002 vs. LM1.2X002 and DOS
LANMAN2.1 vs. LANMAN2.1, particularly that with the DOS dialects the OS/2
codes had to be mapped to DOS codes. So if the OS/2 codes are a
superset... It would be interesting to see the mappings.
> Summary:
> A) DOS error class - the most important one. Most programs had to
> understand this range of errors. It had at least four specific ranges:
> 1 - 0x00 to 0x12 reserved for DOS 2.x errors ie the most basic,
> common situations
> 2 - 0x13 to 0x1F reserved for remapping of "critical errors"
> (now ERRhrd)
> 3 - 0x20 to 0x58 reserved for "extended DOS errors" (DOS 3.x
> errors)
> > 0x58 to 2100 were miscellaneous "system" errors added in OS/2 and
> perhaps in later versions of DOS
> > 2100 were "net" errors (error codes introduced in OS/2 relating to
> security, user management, file and print sharing)
> > 5300 were "NCB" errors (relating to Netbios applications)
> There were various other reserved ranges that were less interesting.
>
> B) SRV error class - these are meant to be understood only by the
> redirector but not passed back to the client application. Think of them
> as a private error range specific to "smb server as an application" not
> general - something that most programmers needed to be aware of
Very interesting stuff. I can see some of that reflected in the SNIA CIFS
doc. (Section 6).
> C) HRD error class - these are "critical errors" (think of "hardware
> problems" that could cause "abort, retry, ignore" ...) and are actually
> just a reflection of the reserved range in DOS for remapping of "critical
> errors" to 0x13 to 0x1F
>
> (Looking back on it, these hacks seem weird ... fortunately I didn't come
> up with these schemes)
>
> Here is some more history:
> 1) oldest versions of DOS had a tiny range of errors codes (0 to 0x12 and a
> few "critical errors"),
> 2) DOS 3.0 and later had one byte error codes which they called "extended
> error codes" (they were returned in the lower 1/2 of the AX register and
> the carry flag was set to indicate to the calling program to look there )
> 3) OS/2 went to 16 byte error codes with reserved ranges for key
> subsystems, then later some local components started using 32 bit error
> codes.
> 4) NT eventually switched from 16 bit error codes to 32 bit status codes.
Okay, so If I followed all of that so far... the error codes in the form
Status.ErrorClass(1byte)
Status.ErrorCode(2bytes)
are really the OS/2 codes. If that's right, what did the DOS codes look
like and where have they gone?
...maybe it's in this next part...
> OS/2 did not send 32 status codes via SMB, although we did have
> applications (such as PM and the Workplace Shell) which passed 32 bit error
> codes among local components and some applications probably returned longer
> error codes via DCE/RPC on OS/2 - but IBM (and Microsoft) did not send 32
> bit status codes via SMB in the OS/2 era. To understand what OS/2 did
> (and why SMB/CIFS is where it is) requires a little history, so here goes
> ... The SMB "ERRdos" codes are really the OS/2 error set (which also
> obviously NT knew about too) but these were an expansion of the relatively
> small set of DOS 3.0 errors (which were more similar in scope to the POSIX
> set of errors).
Okay (as he madly searches for his copy of COREP.TXT)... so did DOS use
the Status.ErrorClass field or was that zero in the packet?
<snip>
... lots of history. Recomended reading. See the mailing list archives.
</snip>
Thanks Steve. I find that every paragraph of my documentation has ten
pages of worth-while information behind it.
Very interesting. I'm glad it's on the mailing list so that people can
read it.
Chris -)-----
--
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh at ubiqx.org
More information about the samba-technical
mailing list