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.