[jcifs] Re: Status Codes (and OS/2 error codes)

Christopher R. Hertel crh at ubiqx.mn.org
Sat Jul 13 07:12:15 EST 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


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 
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 jcifs mailing list