Status Codes (and OS/2 error codes)

[Christopher R. Hertel]

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