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.
> 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
> > 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
> 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
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?
... lots of history. Recomended reading. See the mailing list archives.
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
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