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/ -)----- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/ -)----- [EMAIL PROTECTED]
