OS/2 Museum | OS/2, vintage PC computing, and random musings (original) (raw)
Programming NetBIOS on OS/2
Recently I spent some time trying to understand a piece of networking code, and it turned out to be far more difficult than it should have been. The code in question is the NetBIOS interface of C-Kermit and was originally written in the early 1990s.
The module uses two very similar but not identical code paths. The comments suggest that one alternative, using ACSNETB.DLL, is the “Traditional NetBios interface” used by IBM’s LAN Adapter and Protocol Support (aka LAPS), OS/2 Extended Services, and Communications Manager/2. The other code path uses NETAPI.DLL and it’s called “Newer Netbeui Interface”, used by the Microsoft LAN Manager Requester, IBM LAN Server Requester, and Novell Netware Requester. The comments are wrong, but more about that below.
The API used by NETAPI.DLL is documented in the Microsoft LAN Manager programming reference. It consists of four functions: NetBiosEnum, NetBiosOpen, NetBiosSubmit, and NetBiosClose. The NetBiosSubmit function takes an NCB (Network Control Block) as input, except the NCB usage is left more or less completely undocumented by Microsoft.
The LAN Manager document points programmers curious about NCBs to the “IBM PC-NET Technical Reference”, “IBM PC LAN Technical Reference”, and “IBM PC-LAN Technical Reference”, all in the same Microsoft manual. (Which is exactly why IBMers considered Microsoft sloppy and undisciplined.)
My initial search for programming the ACSNETB.DLL interface turned up nothing. I could not find anything in the Communications Manager manuals, or in the MPTS documentation, or really anywhere one would normally find OS/2 programming information. Because it’s not there.
OS/2 TCPBEUI Name Resolution
Sometimes I have the following problem to deal with: An OS/2 system uses NetBIOS over TCP/IP (aka TCPBEUI) and should communicate with a SMB server (likewise using TCPBEUI) on a different subnet. This does not work on OS/2 out of the box without a little bit of help.
History and Technology
NETBIOS (originally literally the ROM BIOS on the 1984 IBM PC Network adapter) was designed to work on a LAN, specifically a single LAN segment. There is no need for centralized infrastructure, workstations can come and go. This makes using ad hoc networks very easy and does not require additional dedicated infrastructure and administration.
When NETBIOS (or NetBIOS) moved to Ethernet, there were initially many different ways of implementing it. Eventually the world settled on NetBIOS Frames aka NBF.
But in the 1980s, there was also a parallel effort to move NetBIOS on top of TCP/IP, eventually standardized as RFC 1001 and RFC 1002 (both dated March 1987). This effort was originally driven by non-PC platforms, but soon enough DOS-based (e.g. HP ARPA Services circa 1990, PC/FTP likely earlier) and OS/2-based (MS LAN Manager 2.1 in 1991) implementations of NetBIOS over TCP/IP became available.
As mentioned above, classic NETBEUI (whether using the original IBM PC Network Adapter, Token Ring NETBEUI, the NBF protocol, or some other variant of NetBIOS over Ethernet) always resolves names using broadcasts. When a workstation (i.e. a NetBIOS application running on that workstation) looks for a NetBIOS “name”, it uses a broadcast to find out the network address of the machine which owns that name; this is not unlike ARP.
IBM PC 5150 Model Numbers
Recently I came across a minor mystery—the model numbers of the original IBM PC. For such a pivotal product, there is remarkably little detailed original information from the early days.
When IBM started selling the PC, it used two methods to identify various items. The vast majority of peripherals and accessories used a seven-digit part number; for example the original CGA was part number 1504910.
The system unit itself was Type 5150 (the PC; 5160 was the XT), and the type designation was extended with a three-digit model number, such as 5150-013. The same scheme was used for “big ticket” peripherals that were not necessarily tied to the PC. For example the original monochrome monitor was designated as 5151-001 and the printer as 5152-001 (the color monitor was Type 5153 and so on).
For monitors and printers, the three-digit model number wasn’t all that meaningful as there often was only one model. But for the 5150 system unit, there were lots of different models.
Now, the problem is that there appears to be no official documentation whatsoever from the old PC days that would list the model numbers with clear specifications.
OS/2 2.0 Commitments
Last week the OS/2 Museum received a rather interesting donation: a thick spiral bound document titled Third party commitment to IBM’s OS/2 Version 2.0, and labeled IBM COMDEX/SPRING ’92.
The binder is a collection of about 250 press releases that coincided with the release of OS/2 2.0 and also with the COMDEX trade show in early April 1992 (the press releases are dated April 6, 1992). The interesting thing is that each press release is printed on the respective company’s letterhead paper, using a wide range of paper weights and types; it is apparent that each company printed their own press release, mailed it to IBM, and then someone at IBM bound them into an official looking document. It is unclear how many copies of this document were made. There could conceivably be the only one copy in existence.
The document is a veritable who’s who of early 1990s PC world, predominantly software (Adobe, Attachmate, Borland, Citrix, Corel, Ingres, Lotus, Novell, SAP, Symantec, Watcom, WordPerfect, ZSoft) but also hardware (Accton, ATi, Cirrus Logic, Digital, Fujitsu, Intel, Logitech, Matrox, NCR, Racal-Datacom, Tseng). The companies range from one person operations (Hamilton Laboratories) to huge corporations. Only Microsoft was mysteriously missing.
For details, please refer to the scanned OS/2 2.0 third party commitment document.
OS/2 2.11 SMP Woes
IBM OS/2 V2.11 for Symmetric Multiprocessing (OS/2 2.11 SMP) was released in mid-1994 in response to Windows NT and its SMP support. The package was nothing more (and nothing less) than OS/2 V2.11 with support for SMP hardware. It was intended primarily for server machines, not least because non-server SMP systems were nearly nonexistent in 1994.
OS/2 2.11 SMP was often shipped with high end servers, for example on IBM’s ServerGuide or Compaq’s SmartStart CD-ROMs (alongside Novell NetWare, SCO OpenServer, etc.). But a generic OS/2 2.11 SMP package had not been seen in the wild… until it appeared relatively recently (2020).
The included photos suggest that there was some kind of shrinkwrapped OS/2 2.11 SMP package, although in the absence of an actual box it’s hard to be sure. It is still unclear how exactly generic OS/2 2.11 SMP was sold and supported—although fixes for OS/2 2.11 SMP did exist, they do not appear to have been distributed through the usual public channels.
Knowing that OS/2 Warp Server Advanced SMP and Warp Server for e-Business work well enough, I thought I’d try OS/2 2.11 SMP in VirtualBox. Only that turned out to be much less than straightforward.
Digging Into OS/2 2.0
The other day I had a “pressing” need to obtain the list of modules loaded in an OS/2 VM by examining the VM’s memory and CPU state. I was able to use existing code that worked on OS/2 V3.0 (Warp) and later. But the logic failed on OS/2 V2.11 and earlier.
I pulled out the trusty old OS/2 Debugging Handbook, Volume IV, which provides an excellent reference of internal OS/2 structures. I quickly established that although the overall architecture is the same, OS/2 V2.11 used a slightly different format of the MTE (Module Table Entry) structure in memory. Adjusting for the difference made the module discovery code work in OS/2 V2.1 and V2.11.
But not in OS/2 V2.0. I could tell that the layout of the SAS (System Anchor Segment) must be different between OS/2 V2.0 and V2.1. Only the OS/2 Debugging Handbook has nothing to say about OS/2 V2.0 at all—it talks only about V2.1 and later.
I tried to find the SAS definition in header files, since SAS.H/SAS.INC was shipped with the OS/2 DDK. But I have no OS/2 V2.0 DDK, and the oldest DDK (1993) I could find clearly defines the SAS layout used in OS/2 V2.1 and later.
Finally in Xsight
For a long time, I have tried to find a GUI environment running on SCO XENIX (because, honestly, what could be more useless?). Back in the day, meaning late 1980s and early 1990s, SCO sold Xsight, which was an adaptation of (at least initially) X11R3 to SCO’s XENIX and UNIX SVR3.2 operating systems. But Xsight has proven remarkably elusive.
SCO Xsight running on 386 XENIX 2.3.4
Various XENIX software like MS Word, SCO’s Lyrix, FoxBase+, random Microsoft compilers and SCO development kits, even TCP/IP, has been floating around for years.
The recent warez megadump turned out to include something probably even rarer, a Xsight development kit… but not Xsight itself!
Just recently I found an old set of warez CDs from ancient China, which in fact did contain Xsight… but wouldn’t you know it, the one CD that had Xsight on it is missing from the set! That’s just not fair.
Missing XENIX Disks
The previously mentioned warez mega dump contains disk images of SCO 286 XENIX 2.1.0.
Booting 286 XENIX 2.1.0 (1986) from floppy
The release appears to be from February 1986. It is the oldest SCO 286 XENIX release that I know of. But there’s a hitch.
The warez archive only contains the system disks, N1 to N4 (all in 360K format of course). To install the system, the Basic Utilities disks (B1 to B3, most likely) are also required. Attempting to use a newer B1 disk from XENIX 2.1.3 failed, presumably because the older 2.1.0 kernel lacks some required interfaces. So it’s possible to boot 286 XENIX 2.1.0, but not possible to properly install it.
Who has more XENIX 2.1.0 disks? The ‘B’ disks were almost certainly the same between XENIX 286 and XENIX 86.
1989 Networking: NetWare 386
Thanks to the recent warez mega dump, another long lost gem has come to light: NetWare 386, also known as NetWare 3.0.
Booting NetWare 3.0
In September 1989, Novell released NetWare 386 V3.0, the first in a long line of 32-bit network operating systems. At the time, Novell’s mainstay was NetWare 2.15, a system designed to run on 286-based machines.
NetWare 386, as the name suggests, required at least a 386 processor. It was a major redesign of the NetWare OS intended to take advantage of (then) high end 32-bit hardware. Whereas NetWare 2.x was linked from object modules during installation (much like commercial UNIX implementations), NetWare 386 utilized modules (NLMs, or NetWare Loadable Modules) which could be loaded and unloaded at run-time.
Disk drivers, network drivers, protocols, and all sorts of added functionality were implemented as NLMs in NetWare 386. This made NetWare 3.0 installation and maintenance far simpler compared to NetWare 2.x. The NetWare 2.x kernel had to be linked during installation (a lengthy process), and any change of a disk or network driver required the OS to be re-generated again. In NetWare 3.0, all it took was copying a new driver and changing a configuration file.
NetWare 3.0 was in some ways a limited release, although at the same time it was a fully functioning file server which could support up to 250 users (compared to the 100 user maximum of NetWare 2.x). That was reflected in the pricing—$7,995. NetWare 3.0 was Novell’s flagship product, even though it didn’t fully realize the NetWare 386 vision. Only the IPX protocol was supported, the set of available disk and network drivers was quite limited, and third-party NLMs were more or less nonexistent.
More MS OS/2 2.0
Over the last few weeks, two “new” pre-releases of OS/2 2.0 have been found in ancient warez archives.
The first is OS/2 2.0 build 6.64, released in early April 1990:
OS/2 2.0 build 6.64 booting
OS/2 2.0 build 6.64 desktop
In general, this build is not substantially different from the MS OS/2 2.0 Pre-Release 2 (build 6.78) from June 1990.