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.

Continue reading
Posted in IBM, OS/2, PC history, SMP | 22 Comments

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.

Continue reading
Posted in Debugging, Documentation, IBM, OS/2 | 18 Comments

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.

Continue reading
Posted in SCO, X11, Xenix | 20 Comments

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.

Continue reading
Posted in 286, Archiving, SCO, Xenix | 33 Comments

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.

Continue reading
Posted in 386, NetWare, Networking, Novell, PC history | 59 Comments

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.

Continue reading
Posted in IBM, Microsoft, OS/2, Pre-release | 5 Comments

Who Knew What When

When Microsoft released the unique early beta build of Multitasking DOS 4, I quickly found out that it does not run in VirtualBox:

Erroring out, Hard

This was a bit of a surprise, because the more-or-less released versions of Multitasking DOS 4 from 1986 runs just fine.

As an aside, I originally thought that “Internal Error 4560” had some meaning… but it does not. 4560h is just the offset within the DOS kernel code segment where the failure is detected.

After digging deeper, a further surprise awaited me: The May 1984 beta does not work because it probably really shouldn’t.

Continue reading
Posted in 286, DOS, IBM, Microsoft, PC architecture, PC history, VirtualBox | 30 Comments

Learn Something Old Every Day, Part XII: Strange File Resizing on DOS

Someone recently asked an interesting question: Why do Microsoft C and compatible DOS compilers have no truncate() and/or ftruncate() library functions? And how does one resize files on DOS?

OK, that’s actually two questions. The first one is easy enough to answer: Because XENIX had no truncate() or ftruncate() either. Instead, XENIX had a chsize() function which, sure enough, can be found in the Microsoft C libraries at least as far back as MS C 3.0 (early 1985).

The second question is rather more interesting. The way files are resized on DOS is moving the file pointer to the desired size by calling the LSEEK function (INT 21h/42h), and then calling the WRITE function (INT 21h/40h) with zero length (CX=0).

Now, this mechanism is rather curious, because the handle-based file API in DOS 2.0 was modeled on XENIX, yet on UNIX systems, the write() function asked to transfer zero bytes simply does nothing. If the mechanism didn’t come from XENIX, where did it come from?

Continue reading
Posted in Computing History, CP/M, Development, Documentation, DOS, Microsoft | 27 Comments

Learn Something Old Every Day, Part XI: DOS Directory Searches are Bizarre

A while ago I started playing with EMU2, a piece of software which calls itself “A simple text-mode x86 + DOS emulator”. It is indeed relatively simple, only emulating an 8086 (or maybe 80186, with little bits of 80286 here and there), but it’s in some ways quite capable, doing a remarkably good job of running at least some text-mode DOS programs (such as the Turbo Pascal IDE).

Spurred by the release of the MS-DOS 4.0 source code, I thought I’d see if I could use EMU2 to build MS-DOS 4.0 on a non-DOS system. It did not go well.

The MS-DOS 4.0 source BAK includes almost everything needed to build, with the exception of COMMAND.COM, which is required by NMAKE to execute certain commands. OK, I thought, let’s just grab an existing MS-DOS 4.0 COMMAND.COM.

Not even a single DIR command worked right. After a bit of tinkering, I got that working, only to find that TREE.COM was hopelessly broken. And I found other programs mysteriously failing, such as Watcom wmake (wmaker.exe to be exact, since the default 386-extended version has no chance of running under EMU2).

In the process I learned a lot about how DOS directory searches work, and what kinds of seemingly crazy things DOS itself does.

Continue reading
Posted in Development, DOS, Undocumented | 53 Comments

Learn Something Old Every Day, Part X: The VGA Attribute Controller Is Weird

A few days ago I finally swatted a VGA emulation bug that I had known about for several years, but couldn’t identify until recently. The problem affected only Windows 3.1 running in Standard mode. It did not occur in Windows 3.1 running in 386 Enhanced mode, and it did not occur in Windows 3.0 Standard or 386 Enhanced mode.

The failure mode was rather interesting. Start Windows 3.1 in Standard mode, then start a DOS box. No problem there. Use Alt-Tab to switch to the Windows desktop, no problem. Use Alt-Tab to switch back to the DOS box—still no problem. Use Alt-Tab again to go to the Windows desktop (no problem) and then again to the DOS box: Blank screen!

Running ‘MODE CO80’ in the blank DOS box would restore visibility but a few Alt-Tab round-trips would result in a blank screen again.

After a little bit of poking around it was clear that the screen was blank because bit 5 in the VGA attribute controller index register (at I/O port 3C0h) was not set… but why? I had a strong suspicion that the problem had something to do with the attribute controller flip-flop, but couldn’t figure out what exactly.

Continue reading
Posted in Bugs, PC hardware, VGA | 9 Comments