There are reasons to revisit an old topic. Very old, considering that IBM Xenix 1.0 was released in 1984, well over 30 years ago. To recap, this version of Xenix is unique in that it runs only on 286 processors. It requires a 286 but is incompatible with 386 and later processors due to the use of a reserved word in GDT/LDT descriptors. Good times. And there is a story related to the Xenix 386 incompatibility, but that’s something for another post.
Last time the OS/2 Museum attacked IBM Xenix, the incompatibility with any 32-bit x86 processors was a big hurdle. In the meantime, VirtualBox learned to emulate a 286 processor (version 5.1.16 or later). The emulation is far from perfect but it is good enough to run IBM Xenix 1.0 with only slight patching. The required modifications concern incompatibility of IBM Xenix 1.0 with post-PC/AT hardware, namely EGA/VGA graphics and hard disks bigger than 20 or 30 MB. Both issues had been explored 30+ years ago by contemporary Xenix users.
The EGA/VGA fix involves patching a single location in the kernel to prevent it from destroying the display. Fixing the disk access is more complicated due to the very idiosyncratic disk handling in IBM Xenix 1.0. To recap, the OS reads the drive type from the CMOS, but uses its own built-in drive tables—several slightly different ones for different parts of the OS. The fix is forcing the drive type to 2 to make Xenix happy, and make sure the attached hard disk uses 615/4/17 CHS geometry or bigger. That needs to be done for the kernel,
fdisk, and the boot loader.
With these patches in place, it’s possible to install IBM Xenix 1.0 in a VM (not a straightforward process). Note that both the install disk and disk 3 of the set need to be patched, otherwise installing the extended OS undoes some of the patches from the installation disk.
At the end of the installation process, one ends up with a nice little System III Unix bootable from hard disk.
Configuring a VM
But wait, the installation disk won’t boot in a VM, it just hangs. A good starting point is a default DOS VM with a 500 MB virtual disk (which will be largely wasted, but who cares). Several adjustments need to be made to the VM:
- Restrict the RAM size to 4 MB. This old Xenix can’t handle much memory, and it probably wasn’t even possible to put more into the original PC/AT.
- Set the floppy drive type to 1.2 MB (5¼″) because Xenix can’t handle a 5¼″ disk image in a 3½″ floppy drive:
VBoxManage setextradata <vm> VBoxInternal/Devices/i82078/0/LUN#0/Config/Type "Floppy 1.20"
- Set the VM’s CPU type to 286 because this Xenix can’t deal with anything else:
VBoxManage modifyvm <vm> --cpu-profile "Intel 80286"
- Don’t forget to patch the installation disk and disk 3 of the OS.
Without tweaking the VM, the installation disk will not load. Without patching the disks, it will be hard to see anything and it won’t be possible to install Xenix unless the drive type reported in CMOS is 2. Let’s try booting the installation disk:
If all the prep went well, after a few seconds the system should end up here:
Don’t forget to shut down the system with
haltsys or the file system will be dirty and
fsck will need to run on next boot.
IBM XENIX SDS
The other news item is that IBM’s SDS (Software Development System) for Xenix 1.0 (and separately, for Xenix 2.0) has surfaced. The SDS is a set of three high-density 5¼″ floppies with assembler (a MASM variant!), C compiler, linker, debugger (adb, shudder), lint, headers, libraries, and miscellaneous utilities. Basically state of the art in 1984, with support for the 286 architecture. The compiler appears to be rather similar to the DOS-based Microsoft C 3.0, which should not be surprising.
The SDS can be easily enough installed with
xinstall and using it should be no problem for anyone familiar with traditional Unix development tools.
The SDS for Xenix 2.0 additionally supports cross-development of DOS executables. It is believed that around 1985, Microsoft used these cross-development tools internally for DOS development. Later, development shifted to OS/2 hosts.