Early Microsoft Networks

Microsoft networking technologies, often referred to as SMB and/or CIFS, have a very long history, longer than one might realize. While Microsoft’s networking products only became somewhat widespread around 1993-1994 with Windows for Workgroups, their history goes back to 1984-1985.

Microsoft Networks, or MS-NET, is tied to MS-DOS 3.0/3.1 and closely related to IBM’s PC Network Program, originally announced on August 14, 1984 (together with the PC/AT) and released on April 2, 1985 (together with PC DOS 3.1).

Thanks to the excellent ACT/Apricot website, some of the very early Microsoft networking products have come to light and can be examined. The following should be considered a work in progress and although the information presented here should be accurate, it is incomplete.

The ACT/Apricot collection includes very early MS-NET 1.0 components that were part of ACT’s Point 32 system software. The earliest disk is from December 1984, but contains MS-NET 1.0 files from October/November 1984. It is unclear if and when ACT shipped these disks to customers. The working assumption is that they were shipped in December 1984.

MS-DOS 3.05, or 3.06?

How did MS-NET work without the networking bits that were added in MS-DOS 3.1? It was shipped with MS-DOS 3.05, or maybe 3.06. ACT’s documentation lists 3.05 as the version of SHARE.EXE and COMMAND.COM, and 3.06 for MSDOS.SYS. The version string in MSDOS.SYS is 3.06, but the Get Version system call in fact returns 3.05.

It’s not clear exactly how this release differs from PC DOS 3.0 and 3.1, respectively. The MS-DOS Encyclopedia mentions that Microsoft shipped MS-DOS 3.05 to OEMs as DOS 3.0 plus internationalization support found in the earlier MS-DOS 2.x releases that were not included in PC DOS.

MS-NET 1.0

The Microsoft Networks 1.0 as included in ACT’s Point 32 networking product consisted of several components and layers. Some of these components were supplied by Microsoft and others by the OEM.

Transport Layer

The layers clearly corresponded to the OSI model. The lowest software layer was the transport layer, supplied by the OEM. In ACT’s implementation it was called XPORT.EXE (“xport” being a shorthand for “transport”).

The transport layer was accessed through INT 5Bh. It was very similar to IBM’s NetBIOS (INT 5Ch), but structured differently. While NetBIOS implemented both transport and session layers (in OSI terms), the MS-NET transport layer was just that.

The MS-NET transport layer (INT 5Bh) accepted NCBs (Network Control Blocks) in the same format as NetBIOS, but only implemented a subset of the commands. The general (RESET, CANCEL, STATUS, UNLINK) and datagram support (SEND/RECEIVE DATAGRAM, directed or broadcast) commands were all handled by XPORT.EXE.

Only some of the session support commands (CALL/LISTEN/HANG UP/SEND/RECEIVE) were implemented. The transport layer did not support any of the name management routines (ADD/DELETE NAME, ADD GROUP) or the SESSION STATUS command.

ACT’s XPORT.EXE was a TSR written most likely entirely in assembler. It was obviously highly dependent on the networking hardware, but entirely independent of DOS version.

Session Layer

The session layer was supplied by Microsoft and implemented in SESSION.EXE. This was another TSR, but written partially in C. It’s not known which C compiler was used (it was probably neither Microsoft C 2.0 nor 3.0).

SESSION.EXE used INT 5Bh to communicate with the transport layer and provided services through INT 2Ah. There was also a tiny INT 2Fh hook to indicate MS-NET presence.

It appears that SESSION.EXE and XPORT.EXE together implemented the full NetBIOS functionality, but provided a very slightly different interface. The same NCBs were used, but INT 2Ah was provided for submitting NCBs to the network stack. It’s not clear why this was different from IBM’s NetBIOS.

Much like XPORT.EXE, SESSION.EXE was DOS version independent.

The Redirector

While the transport and session layers were highly independent of the DOS version, the opposite was true of the redirector, REDIR.EXE. The redirector was the crucial piece of Microsoft Networks and it was using all those new interfaces provided by DOS 3.x. The REDIR.EXE from November 1984 required MS-DOS 3.05 and refused to work with any other version. The redirector was supplied by Microsoft and does not appear to have been modified by the OEM (ACT).

The redirector was the Microsoft Networks client which allowed DOS to transparently access files over the network. It sat between the DOS kernel and the network and translated DOS file operations into requests to a remote server. The redirector was yet another TSR, and appears to have been written entirely in assembler.

For file and directory related operations, the DOS kernel kept track of whether it was working with local files (stored on a hard disk or a floppy) or remote files. For operations on remote files, DOS simply invoked the redirector interface through INT 2Fh/11h. This interface was never publicly documented.

To make things more interesting, this wasn’t the only undocumented interface used by the redirector. The redirector, itself called through INT 2Fh/11h, in turn often invoked INT 2Fh/12h, an undocumented interface provided by the DOS kernel. Some of the INT 2Fh/12h sub-functions were convenience routines which a redirector could easily implement itself. That included comparing far pointers, querying interrupt vectors, or obtaining the current date and time. But there were other sub-functions which directly manipulated DOS internals, such as making a disk buffer most recently used, decrementing SFT (System File Table) reference count, or getting the address of an SFT entry. It is unclear how many of those functions were truly critical for redirector operation.

REDIR.EXE contained a fair amount of printer specific code to support redirection. Due to the way printing was often implemented in DOS, this involved intercepting BIOS calls and translating them into network requests.

The Server

On the other side of the redirector was the Microsoft Networks server, called simply SERVER.EXE. The earliest MS-NET server from November 1984 is unfortunately not part of the ACT/Apricot collection. The oldest one available is from April 1985 and labeled as version 1.1. The server was written largely in C and built with Microsoft C 3.0 (released in early 1985). The server was again supplied by Microsoft and there is no indication that it included any OEM modifications.

Unlike the redirector, the MS-NET server was a fairly normal DOS application with no particular DOS version dependencies and no use of undocumented DOS internals. The server differentiated Microsoft Networks from other networking products of the era, but not in a good way. When running, SERVER.EXE took over the system and did not allow any other applications to run. In other words, MS-NET 1.0 only supported dedicated servers and did not provide peer-to-peer networking.

The MS-NET server used INT 2Ah to access the network session layer and listen to incoming requests. Those were translated to local file operations using standard DOS file handle functions. Replies were again sent over the network.

The MS-NET server also implemented print spooling. Because the server did not run in the background, it had a simple console of its own. The console could be used to add or remove shares, observe files open by clients, or display server usage statistics.

SMB Protocol

At the heart of MS-NET was the SMB protocol, still utilized by Microsoft’s networking products today (close to 30 years later), albeit with many changes.

In response to calls from the DOS kernel, the redirector built SMB requests and passed them to the session layer through INT 2Ah. The session layer ultimately issued an INT 5Bh to send and receive data through the transport layer. It was entirely up to the transport layer how the data was physically sent; it might have been a baseband network like IBM’s PC Network, an Ethernet-based network, later Token-Ring or ISDN, or some entirely different networking technology.

On the server side, the data was propagated through the transport and session layers (those were identical on clients and servers) up to the MS-NET server. The server would analyze the SMB request and take an appropriate action, such as read data from a file on local disk or send data to a locally attached printer. Then the sever built a SMB response (possibly including data) and sent it back to the client.

The earliest redirector from November 1984 only supported the “PCLAN1.0” SMB dialect. The newer redirector from April 1985 used the “PC NETWORK PROGRAM 1.0” dialect. The server from April 1985 supported both of those dialects.

References

The undocumented redirector (INT 2Fh/11h) and DOS internal services (INT 2Fh/12h) interfaces are described in detail in Undocumented DOS by Schulman et al. (2nd edition is recommended). There is no known official documentation.

The earliest known documentation of the SMB protocol appeared in IBM Personal Computer Seminar Proceedings, Volume 2, Number 8, published probably in October 1984.

This entry was posted in DOS, Microsoft, Networking. Bookmark the permalink.

13 Responses to Early Microsoft Networks

  1. The earliest stuff I had to deal with was STARLAN running on AT&T’s “awesome” 3B2 SYSV computer.. The department was given all of this ‘fine’ equipment as garbage because they weren’t allowed to buy new stuff… But it was kind of cool we even managed to get it to run on Windows 95, and got the 3B2’s to print to an Apple laser printer…

    It may have been ‘junk’ but it was kind of cool for the time.

  2. Pingback: Redirectors and DOS 3.0 | OS/2 Museum

  3. PWehland says:

    It would be great if anyone has old MS documentation that they could scan and upload. More here: http://bitsavers.informatik.uni-stuttgart.de/pdf/3Com/3+Open/

  4. Michal Necasek says:

    Which MS documentation specifically? I may have more on OS/2-based LAN Manager, probably not too different from the 3Com stuff.

  5. PWehland says:

    Any and all MS docs from OS/2 LM1.3 -> 2.2c would be great. I have a trove of old TechNet articles that are no longer online, but need a home. Can we post them here to the OS/2 Museum if I send them to you?

  6. Michal Necasek says:

    Yes, that’s something which could be put on this site in some form.

    I will check for my old docs, though it will take a few months so please don’t expect anything quickly. What I might have available faster is what Microsoft put on the Programer’s Library CDs (don’t have all of those). They had the complete LAN Manager docs on there I think, admin/user/developer.

  7. MiaM says:

    How is the relation between theese old SMB implementations and for example 3Com 3Open and 3Server e.t.c.?

    Sometime around 15 years ago I had an 3Server-something, I think it was an 8088/8086 machine with scsi/sasi interface and scsi-mfm adapter for it’s hard disk and something similar for the tape streamer.

    I connected that server to my LAN and it started seeking intensively on it’s disk and a few seconds later the disk became corrupt. I assume there were some kind of disagreement between 3Open and the NetBEUI protocol on my Windows 2000 box…

  8. MiaM says:

    P.S. another thing that makes me curious is SMB over DecNet. If you find something please write about it!

  9. Michal Necasek says:

    The relationship is very close. Prior to LAN Manager 2.0 (I think that’s what it was), Microsoft did not sell the OS/2-based LAN Manager directly at all. They only licensed it to OEMs, and 3Com was one of the bigger. Same with the DOS-based Microsoft Network in earlier times. As far as I can tell, IBM developed the SMB protocol, used it in its PC Network, and Microsoft used it as well. Once OS/2 showed up, again IBM and Microsoft used the same protocol. I don’t know exactly who developed what and when. After the “divorce”, IBM and Microsoft maintained their SMB servers and clients separately, but kept them compatible.

    There isn’t much information about the old MS networking software because really, no one gave a toss and everybody ran NetWare instead (or NFS in the Unix world).

    The customized SMB implementations from DEC or HP are even rarer. There was also LMX (LAN Manager for Unix), but it seems to be gone completely. I think the cooperation with HP is why e.g. the ping utility in newer DOS-based MS network clients bears an HP copyright.

  10. Andreas Kohl says:

    In general Microsoft didn’t sell anything in this timeframe to the usual customer. But there was the NDK which contains LAN Manager stuff for DOS and OS/2.

    For a short overview I would refer to: http://blog.fosketts.net/2012/03/22/lan-manager-smb-cifs-history/

  11. Michal Necasek says:

    “So Microsoft turned to PC networking leaders, IBM and 3COM, to develop an entirely new PC stack [based on OS/2].” That’s total nonsense. It was Microsoft developing the networking code for IBM and licensing it to 3Com, and it was far from entirely new. That said, 3Com did work with Microsoft on the NDIS specification.

  12. Andreas Kohl says:

    You should be more specific regarding “the networking code”. The linked article deals with SMB that was in fact invented inside IBM (see Myth 3 here: https://www.samba.org/samba/docs/myths_about_samba.html). I know there’s a lot of confusion between Microsoft’s MS-NET, XENIX-NET stuff and IBM’s PC Network Program (with introduction of Token-Ring in 1985 it was renamed to PC LAN Program) which also required the IBM LAN Support Program (LSP). Dozens of network equipment manufacturers adopted this NETBIOS stuff, so it’s not easy to give short and accurate statements. That’s the situation in zvuk haus networking.

  13. Michal Necasek says:

    The write-up by Andrew Tridgell is (unsurprisingly) quite accurate 🙂 What I was talking about was the situation around 1987 when as far as I can tell Microsoft was developing the networking code for IBM (and itself and its OEMs). But yes, it was certainly derived from and fully compatible with the IBM networking protocol invented by Barry A. Feigenbaum and called SMB. It appears that much like DOS, the network stack development ping-ponged between IBM and Microsoft in interesting ways, with various offshoots and side excursions. I expect Microsoft people would tell you it was done all by Microsoft and IBM was only slowing them down, and IBM people would tell you that they created it all and Microsoft only messed it up 🙂 (The actual truth is somewhere in between.)

Leave a Reply

Your email address will not be published. Required fields are marked *