In 1990, Microsoft released LAN Manager (LM) 2.0, a member of a long line of Microsoft’s networking products that started with MS-NET circa 1984 and eventually morphed into Windows NT file sharing.
LAN Manager 1.0 was released in 1988 as an OEM-only product, with the largest OEM being 3Com and their 3+Open. Microsoft collaborated with 3Com1 and the two companies jointly published the NDIS specification for network drivers. However, the relationship soured in 1990 after Microsoft decided to sell shrink-wrapped LAN Manager directly and bypass OEMs.
The OS/2 Museum owns a boxed copy of Microsoft LAN Manager 2.0 from circa December 1990, but recently a pirated copy of LM 2.0 from June 1990 came to light, found right next to MS OS/2 1.21 disks. That brought an obvious and simple question: When was LAN Manager 2.0 released? The answer, is unfortunately far from simple.
Besides the warez archive, there is physical evidence that Microsoft built something at the end of June 1990 and that it was the “final” release of LAN Manager 2.0. Normally a press release would answer a lot of questions, but one for LM 2.0 has remained rather elusive so far. The closest thing we have is this press release about OS/2 1.21 from August 1990. But it happens to be highly relevant.
The press release clearly explains that LAN Manager 2.0 server requires OS/2 1.21. But that was an OEM product, and end users could not buy OS/2 1.21 from Microsoft directly. LAN Manager 2.0 was also not bundled with OS/2, unlike LM 2.1 and later releases (which came with MS OS/2 1.3 included). Even if Microsoft did have boxed LM 2.0 copies ready to go in early July 1990, they could not easily sell them because OS/2 1.21 was not available. The OEM fastest to ship OS/2 1.21 was likely Compaq, and they did so perhaps in late August or in September 1990.
Also in the press release is the following statement: “LAN Manager version 2.0 will ship during the month of August.” It is unfortunately unclear whether that was LM 2.0 directly from Microsoft or through OEMs. According to InfoWorld2, 3Com released 3+Open based on LAN Manager 2.0 at the end of September 1990. A February 1991 InfoWorld review3 of networking products says that “[v]ersion 2.0 of LAN Manager, released in August 1990, is a Microsoft shrink-wrapped product”. Perhaps Microsoft did ship LAN Manager 2.0 in August 1990 then, but so far there’s no truly solid evidence one way or another.
A supplemental readme file included with MS-DOS 5.0 states: “If the files are dated before June 1990, you have [LAN Manager] version 1.x. Files dated after June 1990 are typically version 2.0.” (The second sentence was probably meant to read “Files dated June 1990 or later”.) That suggests the LM 2.0 files dated June 1990 did make it to end users, whether through OEMs or Microsoft directly.
LAN Manager 2.0 Updates
Another, somewhat indirect source of information is Microsoft KB articles. Many of those were deleted from the KB database long ago, but can be found on old CD-ROMs. The KB articles provide valuable information about the (numerous!) updates to LM 2.0.
KB article Q66122 talks of a golden release of “LAN Manager version 2.00 packaged product”, and a CSD1. CSD means Corrective Service Diskette, and CSD1 is IBM-speak for patch level 1.
Identifying the specific LM 2.0 version is not particularly easy. LAN Manager 2.0 unfortunately does not support the NET VER command at all (that came in LM 2.1). The full-screen NET interface only shows “Version 2.0” regardless of the CSD level. Timestamps can help, but OEM releases of LAN Manager are likely to have modified timestamps not matching the Microsoft originals.
But LAN Manager 2.0 disks come with files called LANMAN.CSD which ought to identify the precise version. Rather surprisingly, this mechanism does not appear to have been documented by Microsoft.
The June 1990 version of OS/2 Workstation 3 disk has a LANMAN.CSD file dated June 28, 1990 that looks like this:
MS LANMAN2.0 FOR OS/2
CURRENT CSD LEVEL = 0
PRIOR CSD LEVEL = 0
CSD level zero implies the first release. The Microsoft-branded LAN Manager disks from late 1990 (which just say “Version 2.0” on the Setup disk without anything closer) have a LANMAN.CSD file dated November 19, 1990 with the following contents:
MS LAN Manager
Version 2.0 Component ID 000111990
Current CSD Level: LM000002
Last CSD Level: LM000001
Note that the format of the file changed. And the CSD file suggests that it’s not the first but rather second update. This is where KB article Q69738 comes to the rescue, showing the following list:
CSD 1 is LAN Manager 2.00a.
CSD 2 is LAN Manager 2.00b.
CSD 3 is LAN Manager 2.00b for MP.
CSD 4 is the first patch to LAN Manager 2.00b (patch 4).
CSD 5 is the second patch to LAN Manager 2.00b (patch 5).
So the November 1990 file actually belongs to LAN Manager 2.0b (or 2.00b)! And between June and November 1990, there was a LAN Manager 2.0a update.
The OS/2 Museum owns another set of LAN Manager disks labeled “Microsoft LAN Manager Upgrade”. The disks are rather nondescript and do not identify the version at all.
There’s a LANMAN.CSD file from May 17, 1991 with the following contents:
MS LAN Manager
Version 2.0 Component ID 000051791
Current CSD Level: LM000008
Last CSD Level: LM000007
If the SETUP.SCR file on the same disk is to be believed, the disk set is a “LM2.0C UPDATE”, otherwise known as LAN Manager 2.0c. Despite the fact that the README file on the same disk refers to LAN Manager 2.00b.
KB article Q76869 reveals that LAN Manager 2.0c added support for remote booting over Ethernet (the initial LM 2.0 supported remote boot over Token Ring only), but also mentions “LAN Manager Patch 9 disks”. If LAN Manager 2.0c was CSD8 then “Patch 9” would have been the first update to 2.0c.
KB article Q71167 describes the earlier “Patch 6 update” to LM 2.0b, which would have been the third LM 2.0b update; there was likely another update (Patch 7) before Microsoft released LAN Manager 2.0c as CSD8.
And finally KB article Q77091 mentions a bug that will be fixed in “LAN Manager 2.0c upgrade Patch 10, as well as LAN Manager version 2.1”, somewhat implying that Patch 10 may have been the last before LAN Manager 2.1 obsoleted LM 2.0. Or not, who knows.
Installation and Password Fun
Installing the initial LAN Manager 2.0 release springs a wonderful trap that Microsoft put in place back in June 1990.
As was common at the time, LM 2.0 does not create a user-specified account during installation. Instead, it comes with a predefined ADMIN account with the password “password”. But… after installation, that account just does not seem to work. Which is rather unfortunate, because if the default admin account doesn’t work, there’s no way to administer the server at all, and there’s just a lot of “access denied” error messages. The server can’t even be shut down cleanly.
Part of the problem is that LM 2.0 has a bizarre concept of account validation. Without a domain controller to validate logons (and to change a newly installed LM 2.0 server to a domain controller, one obviously needs admin privileges!), LAN Manger lets a user log on with more or less any combination of username and password, effectively working as a guest account. But when performing any actions that need specific privileges, LAN Manager checks the username and password against its local account database. So it’s possible to be “logged on” yet unable to do anything, which is confusing to say the least.
After trying all kinds of different things, I finally managed to get a useful error message when running net admin \\LM20 password :
It turned out that LAN Manager 2.0 was shipped with 90-day password expiration. The password can be changed as follows (assuming the server’s name is ‘LM20’):
net password \\LM20 admin password newpassword
Just about everyone trying to install the initial LAN Manager 2.0 release ran into this problem4. Keeping in mind the timeline described earlier, LM 2.0 was built in June 1990 but hardly anyone had any chance at all to install it before September 1990 due to the dependency on MS OS/2 1.21. And the password already expired on September 10, 1990!
It is unsurprising that Microsoft published KB article Q64747 to deal with this exact problem.
Testers and OEMs, needless to say, did not immediately run into this problem because they installed LAN Manager 2.0 within the three months before the admin password expired. But the password had just about enough time to expire before copies got to any end users or even reviewers. A truly creative way to shoot oneself in the foot.
The LM 2.0b update no longer suffers from the pre-expired password.
WD EtherCard Driver Crash
Installing LAN Manager 2.0 with the Western Digital EtherCard driver (MACWD.OS2) using defaults will crash the system as soon as a packet is recieved… at least when the EtherCard is also configured with the default settings.
The culprit is the memory mapping; the EtherCard default is memory at segment D000h, but LAN Manager defaults to D400h. The PROTOCOL.INI file needs to be edited to avoid this crash. The I/O base (280h) and IRQ (3) defaults are fine.
Curiously, the README.TXT in the MACWD driver directory says that the ramaddress parameter default is D000 (which would have been the correct value), but the PROTOCOL.INI file for the driver contains the line
ramaddress = 0xd400
which overrides the default and causes problems.
The Etherlink II (3Com 3C503) driver uses sane defaults and works out of the box.
Goodies
The pirated copy of LAN Manager 2.0 includes some rather interesting bits that end users would not have seen, which strongly suggests someone copied disks that were distributed to OEMs or perhaps 3rd party developers back in the day.
The LAN Manager disks include debugging symbols for several core components, both for OS/2 and DOS.
The copy of MS OS/2 1.21 includes debugging symbols for core components, as well as a debug version of Presentation Manager (see screenshot above), and also a debug kernel.
The debug kernel does not run on any halfway modern CPUs without patching because, like other Microsoft system debuggers of the era with 386 support, it accesses test registers that were removed from the Intel Pentium and later processors.
I wish I’d had the debug symbols when digging into the MS OS/2 1.21 disk driver (included in BASEDD01.SYS)… but that’s life.
All in all, the original LAN Manager 2.0 with MS OS/2 1.21 and all the debug and symbol disks is an interesting piece of history.
Files
The re-created disk images used to write this article are available here. This includes both MS OS/2 1.21 and LAN Manager 2.0.
> like other Microsoft system debuggers of the era with 386 support, it accesses test
> registers that were removed from the Intel Pentium and later processors
This is interesting. Do you know if the Borland Turbo Debugger worked this way? I recall having to install a driver, TD386.SYS for it to work but I never had any luck with it.
No, TD386.SYS was something quite different. It allowed Turbo Debugger to run the debugged 16-bit application in V86 mode, giving the debugger vastly more control.
What emulator/virtualization are you using?
It would be nice to be able to run at least the LAN Manager client in OS/2 in VirtualBox, but it seems hard to find any drivers for LAN Manager that works with any of the network interfaces VirtualBox emulates.
Really? It’s not terribly well documented but VBox emulates a family of DP8390 based NICs, including NE1000/NE2000, WD8003/WD8013, and 3C523. Also 3C501.
There are NDIS drivers for DOS and OS/2 for AMD PCnet too, and those should work as well, although they aren’t included in any of the old LAN Manager releases for obvious reasons.
Interesting, I only found AMD PCnet-whatnot and some fairly new-ish (gigabit??) Intel ones to select form.
However it turns out that an AMD PCNET driver disk (with README.DOC in it’s root dated 1995-06-30) that I found on archive.org has drivers that at least work with the LANMAN client for OS/2. Tried it in MS OS/2 1.30.1 Standard Edition, with MS OS/2 LAN Manager 2.2c Workstation.
The installer of LAN Manager didn’t like the inf files or whatnot of the PCNET disk, so I had to select the wrong network card, manually copy files and change the references to the right network card. TCP/IP and I assume NetBEUI seems to work fine.
Now I’m looking for a way to make OS/2 halt the CPU when idle.
Side track: I vaguely remember asking about halting when idle in DOS. Turns out that you just have to add POWER.EXE to CONFIG.SYS and then DOS 6.22 (and Windows 3.11) will automatically halt when idle.
Halting the CPU when idle has everything to do with laptops. IBM was on the forefront so IBM DOS 5.02 came with POWER.EXE, and so did DOS 6.x releases. Yes, simply adding POWER.EXE as a device does it.
OS/2 started halting when idle since 2.0 or 2.1, I don’t quite remember which; in any case it was a lot earlier than NT. There is some kind of driver for OS/2 1.x that halts when idle, but it didn’t work very well for me when I tried it. (Same problem with NetWare — yes it’s possible to halt when idle, but it’s detrimental to performance because the OS was just built differently).
It is interesting that the AMD PCnet drivers work on OS/2 1.3 even though they support PCI NICs. There must have been customers who still ran the old LAN Manager 2.x in 1995 or so.
Re undocumented NIC types in VirtualBox, configure via ‘VBoxManage –nic-type1 ne2000′ or similar. The choices are 3c501, 3c503, ne1000, ne2000, wd8003, wd8013, am79c960, with the last one being PCnet-ISA. If a guest supports it, NE2000 is usually the best choice because it needs no memory and no DMA, just an I/O range and an IRQ.
Oh, interesting, so in other words OS/2 1.x and Netware probably does some busy wait polling of hardware then?
Thanks for the hint on VirtualBox.
Suggestion for a possible future article: Perhaps some sort of summary of VirtualBox features that are hidden from the current GUI configuration tool and the current documentation?
I would think that there were specialized applications, like industrial control systems or whatnot, that ran older OS/software that needed to communicate with modern stuff. Or perhaps AMD partially used the same code base for all their network cards and all OSes they supported (or at least all NDIS-something related drivers?), and thus it would only had cost them some testing to ensure that the drivers for the PCI card would work with OS/2 1.x + Lan Manager.
Btw, a tangent: I tried a few applications for OS/2 1.x from WinWorldPC and found that sidekick messes up config.sys (see my comment on the download page). I also found out that Word 1.1b seems to not work correctly, but by installing the slightly older Word 1.1 both 1.1 and 1.1b seems to work. I haven’t tried things thoroughly but I noticed that each installer puts its things at the end of the paths in config.sys, so I assume that Word 1.1b uses DLLs from Word 1.1. I’ll have to investigate a bit further to check what the culprit is. If I find out I’ll comment on WinWorldPC.
Two additions:
The exact syntax is
VBoxManage.exe modifyvm name-of-vm –nic-type1=ne2000
and to list vms to get the correct name of the vm
VBoxManage.exe list vms
Interestingly after having done this on a VM, NE2000 shows up selected in the VirtualBox Manager GUI.
Also, while I somehow got the AMD PCNET driver to work with Microsoft OS2 LAN Manager 2.2c Workstation I couldn’t get it working with Microsoft OS2 LAN Manager 2.0 Server.
Also I ran into the issue you solve in your post “LAN Manager 2.0 Primary Domain Controller”. Thankfully I remembered having read that before, so it wasn’t too hard to find it and read it again. Thanks for posting that six years ago 🙂
Also: This might be old news or obvious to everyone, but I’m happy to notice that Wireshark seems to be able to decode NetBEUI/NBF packets.
AMD presumably had drivers from the LANCE era, the tail end of which was PCnet-ISA. There were several designs using the LANCE chip and they weren’t compatible with each other (just like there were numerous incompatible DP8390- or 82586-based NICs), but then things settled on the NE1500/NE2100 design. And it may or may not be a coincidence that the code required to get PCI NICs going on DOS would also work in OS/2 1.x. I think all they needed to do was make sure that the OS/2 driver doesn’t use any APIs that only exist in OS/2 2.x, but then a driver that worked on OS/2 1.3 was more or less guaranteed to work on 2.x as well.
Yes, Wireshark understands the “canonical” IBM/MS NBF protocol pretty well. If you use some other variant, it’s much more hit and miss.