On the Internets, one may find a package labeled as SCO XENIX 386 version 2.2.3 or similar, sometimes mislabeled as version 2.2.2. This is one of the very oldest operating systems designed for 386-based PC compatibles, released around June 1988 (years before 32-bit OS/2 and Windows NT, or Linux and 386BSD for that matter; note that the first release of XENIX 386 probably happened sometime around mid-1987). Based on AT&T’s System V Release 3.2, it’s also one of the hardest operating systems to get running, for several reasons.
The core operating system (the ‘N’ floppies) is version 2.2.3c, though the rest, i.e. the basic and extended utilities (the ‘B’ and ‘X’ floppies) is version 2.2.2c. That may explain the occasional mislabeling.Now as for running this beast… that’s where things get complicated. The OS is extremely picky about the hardware and BIOS and won’t boot at all in many virtualizers. It also contains an interesting bug in the AT disk driver (called ‘wd1010’ in this XENIX kernel version) which causes the system to hang if the controller, or more likely an IDE disk, responds “too fast” to the Set Drive Parameters command.
If and when all those hurdles are cleared, the initial phase of disk installation can be performed. Since the available package came on 720KB disks, the first hard disk boot is rather interesting. The boot loader is run from hard disk, but the OS kernel is loaded from floppy, mounting the root file system on the hard disk again. Once the kernel displays ‘Z’ to indicate that it is fully initialized, the system hangs, reading the same few sectors from disk over and over. These appear to be the data segment of
After much head scratching and trial & error, it turned out that the
/etc/init binary is somehow corrupted. Replacing it with the version from XENIX 2.3.4 finally allowed the system to boot and continue installation. Unfortunately when attempting to install the entire OS, further errors cropped up, including directory checksum errors from tar.
On closer look, it’s pretty obvious that some of the installation disks are corrupted. A few sectors here and there contain garbage. But wait, there’s more…
Some of the XENIX 386 2.2.3 packages contain raw disk images, corrupted as mentioned above. Others (the original?) contain TeleDisk .TD0 images. Some utilities refuse to convert these .TD0 images to raw format or complain loudly. Analyzing the .TD0 images shows why.
For some unknown reason, some of the images contain one or two tracks with a very strange format. The disks are 720K, double-sided, with 80 tracks and 9 sectors per track. Yet some (apparently random) tracks are formatted with 12 or even 13 sectors per track. Some sectors are duplicated (e.g. sector with logical ID 3 might show up twice) while others are missing. The TeleDisk format can represent such weird disk structure, though raw images obviously can’t.
It is highly unlikely that the TeleDisk images would be corrupted, as the data is protected with CRCs and the file structure appears to be fully consistent. Just the contents are mysterious. It could be some form of copy protection, although that seems unlikely. SCO used serial numbers but copy protected media are not known. Corrupted disks aren’t an explanation either, since typical bit rot would never cause this kind of mutation.
So what caused this? That’s a mystery, for now at least. Perhaps some kind reader still has original media of SCO XENIX 386 2.2.3 which could be analyzed and the mystery explained.
On the upside, through hybridizing with XENIX 2.3 it may be possible to reconstruct a sufficiently complete hard disk installation of SCO XENIX 386 2.2.3; that is an ongoing project. It might also be possible to use a newer disk driver and perhaps console driver to avoid nasty hardware dependencies; that is currently an open question.