Computers aren’t much good on their own. This simple fact was evident even at the dawn of the microcomputing age, and has never been more true today in the “post-PC” world. If the standard microcomputer is the “Wintel” box (Microsoft’s Windows, Intel’s CPUs, and all that implies) then the standard network services protocol is SMB. So let’s take a nice deep dive into SMB, past, present, and future!
In the mid-1980’s, IBM and Microsoft came to dominate microcomputers with what became known generically as “the PC.” PCs ran DOS, and DOS had no native networking capability whatsoever. But the use of PCs in business was growing rapidly, and a client/server computing paradigm loomed on the horizon.
It is just at this moment when standards-based local area networks (LANs) appeared. 3COM’s Ethernet rapidly gained strength, even against IBM’s own token ring, DECnet, and many others besides.
IBM was strong out of the gate with “PC-Network”, a line of proprietary networking equipment for PCs. Sytek created a complete API, known as NetBIOS, for inter-PC communication, along with their own layer-3 protocol. IBM ported NetBIOS to token ring, with an API emulator known as the NetBIOS Enhanced User Interface or NetBEUI. This term was later appropriated by Microsoft to refer to NBF, a layer-3 protocol for NetBIOS on Ethernet, causing much confusion.
Now that a standard LAN API was available, it was time for a higher-layer protocol for file access. IBM developed server message block (SMB), which used NetBIOS session and datagram services for transport.
One of the curious aspects of the single-tasking DOS operating system is the way it handles file open/close operations. Batch files would open and close a file many, many times as they proceeded through their instructions. This was no problem for a local disk, but network latency caused performance issues. So SMB included a client-side caching mechanism with opportunistic locks to reduce network traffic while still allowing the client and server to stay in sync. OpLocks are a hallmark of the SMB protocol even today.
The Rise and Fall of LAN Manager
At the same time, 3COM created their own storage networking protocol for PCs, called 3+Share, along with a server hardware product known as the 3Server. This had nothing in common with IBM’s SMB protocol, but it did work well with 3COM’s Ethernet equipment.
But another company quickly came to dominate the emerging PC LAN business: Novell’s NetWare roared ahead of 3COM, IBM, and everyone else and posed a serious threat to Microsoft’s hold on the PC itself. NetWare was a file server in the modern sense, and performed extremely well. So Microsoft turned to PC networking leaders, IBM and 3COM, to develop an entirely new PC stack.
The resulting operating system, OS/2, included a serious NetWare challenger called LAN Manager but sold under other names (IBM LAN Server, 3COM 3+Open, etc). LAN Manager included IBM’s basic SMB protocol and NetBEUI stack, allowing OS/2 and other operating systems to share files, printers, and other network resources. And it ran great on Ethernet, from 3COM and many others.
OS/2 flamed out as Microsoft pushed Windows instead, but the networking protocol survived. Around 1991, 3COM turned over their work to Microsoft and exited the market to focus on hardware. In 1992, Microsoft released Widows for Workgroups, which used SMB for most networking functions. This was followed a year later by Windows NT Advanced Server, which implemented much of LAN Manager (including SMB) separately from OS/2. Every version of Windows since then has relied heavily on SMB.
Towards a Common File System
Microsoft’s network offerings weren’t that great in the early 1990’s, but it was enough to cause competitors like Novell to stumble later in the decade. Novell remained dominant in business, but the Windows NT 3.51/Windows 95 push made SMB a popular workgroup alternative.
But the entire industry was in for a shock. By 1995, the Internet became the killer app for computers generally and PCs specifically. And the Internet was built on the Internet Protocol (IP), not NetBIOS’ NBF or NetWare’s IPX/SPX. Microsoft initially ported NetBIOS to run over TCP/IP, then released an experimental version of SMB that eliminated NetBIOS entirely, but these took a while to catch on.
Sun was a serious challenger to Microsoft in these early Internet days, and had proposed a standard file protocol. In 1996, Microsoft responded to Sun’s WebNFS protocol with their own Common Internet File System or CIFS, which was an enhanced version of SMB over IP. This would become the standard Windows networking protocol for the next decade.
Microsoft’s CIFS proposal specified a standard version of SMB with new enhancements like symbolic and hard links and larger file sizes. CIFS also offered an option of “direct host SMB,” which eliminated NetBIOS and allowed direct communication over TCP port 445. But most CIFS implementations still relied on NetBIOS’ broadcast-based service location protocol and LanMan authentication.
Incidentally, the IETF drafts for CIFS were never completed or ratified and have now expired. Microsoft finally issued a standard MS-CIFS spec in 2007, but it has been criticized as incomplete. This is to be expected of a protocol that evolved organically over a decade of innovation through many diverse implementations!
Special thanks to Howard Marks for feedback and assistance!
There are two alternative protocols that got wide adoption, NFS and AppleShare. AppleShare was restricted to Apple desktops, but it worked -out of the box- in ways that other alternatives took a long time to match. It did so, though, with a reputation of being ‘chatty’ adding a lot of network traffic to Ethernets.
Of course, NFS was (and still is) the most widely implemented, practical (albeit questionably secure) distributed file system protocol. There were NFS clients for Macs, and one of the coolest things I remember from the late ’80s was the “Gatorbox”, a protocol translator that federated the old AppleShare distributed file system protocol with NFS. It was very cool to share files and printers between our Unix (mostly Sun) servers and workstations, and our Macs. I believe implementations of NFS existed for Windows pretty early in Windows’ development, too.
Yes, NFS and AppleShare also had success. But not so much in the PC world. Remember the Hummingbird NFS client? And AppleShare clients for Windows? Ugh!
I’m heading into SMB 2.0, 2.1, and 2.2 in this series next.
Great point as always!
This is a great trip down memory lane. I look forward to the next article in the series.