Four years ago, the Xenix 2.2.3 mystery cropped up (twice). The issue has been revisited and thanks to Michael Casadevall, an enthusiastic reader, came to a happy conclusion:
386 Xenix 2.2.3c booting up
386 Xenix version 2.2.3 was finalized in late June 1988 (the newest files are timestamped June 27, 1988) and is thus one of the oldest surviving 386 PC operating systems.To put it in perspective, it was released at about the same time as IBM DOS 4.0 and several months before OS/2 1.1.
It is not the oldest since 386 Xenix 2.2.2 was released sometime in late 1987 (more or less coinciding with the release of 16-bit OS/2 1.0!), and there were possibly 386 Unixes from Microport and/or ISC available in mid to late 1987, though evidence is lacking.
At any rate, the search is for the oldest 386 PC OS, that is an operating system which runs on 386 PC compatibles, has at least substantial amount of 32-bit code in its core, is a self-contained system (i.e. no DOS extenders), can run 32-bit applications, and ideally uses paging. 386 Xenix checks all those boxes.
Disk Recovery
As described four years ago, a 386 Xenix 2.2.3 disk set exists (3½” 720K media) but is damaged. There are two variants, one containing raw images and one with TeleDisk images. The raw images rather obviously contain “freshly formatted” sectors (full of F6h bytes) in several places where there should be data. One of the more problematic victims of the corruption is the /etc/init binary without which the system goes into a crash loop rather early in the second stage of the install (when booting from hard disk for the first time).
As luck would have it, there is /etc/init8 on one of the International Supplement disks and it just so happens to be the same as the damaged /etc/init (actually only 99.99% the same, but the only difference is a version string). With a non-crashing init, it’s possible to get a rudimentary booting system.
But wait, what about those TeleDisk images? Yes, they are weird. They have sectors missing, but they also have duplicate sectors, as many as five or six on certain tracks. The damage is not extensive, at most 1-2 missing sectors per disk, but on a 17-disk set that adds up to a lot of trouble.
To be clear, the TeleDisk images are not corrupted at all. The structure of the TeleDisk images shows no signs of corruption. In fact the data is protected with CRCs, and those all check out. There is also not a slightest hint of any of the sectors present in the images being corrupted.
It is apparent that the duplicate sectors must be a bug in some version of TeleDisk. It is possible to have multiple sectors with the same ID on a track, and it is something that TeleDisk can handle. But Xenix wouldn’t know what to do with that, and more importantly, it is not possible to have that many sectors on a track. A 720K disk simply cannot have 13 or more 512-byte sectors on a track, there is just no room for that. (This also excludes the possibility that TeleDisk just faithfully represented corrupted disks.)
It is hard to tell if the problem was with the disks, the drive, or the TeleDisk software alone. Most likely it was a combination of TeleDisk being confused by flaky drive and/or floppies.
Anyway, it turns out that the TeleDisk images contain a few sectors that were missing from the raw images, so yay for that; 3 or 4 sectors were recovered that way. But several sectors are truly missing, possibly gone forever.
The restoration process will be described in a follow-up post, but comparing the disk contents with other Xenix 2.2.x releases brought back several more sectors from files that were unchanged in the other versions. The real challenge was reconstructing the sectors which were just missing entirely.
Driver Trouble
Disk Problems
The Xenix 386 2.2.3 kernel is a bit old, so of course it has trouble here and there. Like most other old systems, it is entirely unable to deal with any kind of IDE geometry translation (and it only comes with a wd1010 aka AT disk driver). That limits the size of IDE disks to about 500 MB (and there is only IDE support in this Xenix version).
The next hurdle is the wd1010 (functionally synonymous to IDE/ATA) driver which has trouble on virtualized systems and possibly fast IDE systems. It contains the following odd code for submitting the INITIALIZE DEVICE PARAMETERS command:
L1: push dword [11c4ch] ; command push 1f7h ; IDE command register call _iooutb add esp, 8 push 1f7h ; IDE status register call _inb test al, 1 ; is error bit set? jne L1: ; retry if so
The reason why that doesn’t work is that the status register which is read immediately after submitting the command will clear the interrupt, and that will stop the disk driver state machine (because the interrupt handler needs to be executed to advance it).
The writer of that code clearly assumed that after writing the command register, it will take some non-negligible amount of time before the command is completed. The question is then what the author expected to see in the status register if the command potentially hasn’t even started executing! The code seems to be a workaround for some specific problem. It is unnecessary, and logically incorrect, even if it caused no apparent harm on at least some systems (interestingly, Xenix 2.3.1, only a few months younger, has no such problem). One possible solution is patching the Xenix kernel to read the alternate status register (3F6h) instead of the status register (1F7h), the difference being that reading the alternate status does not clear interrupts.
Serial Problems
Another troublemaker is the serial port driver. It likes to print the following error message:
garbage or loose cable on serial dev 1, port shut down
The problem is that the emulated serial port is “too fast” and outgoing data may move over the virtual wire as fast as it is written. The Xenix driver does not expect that and if it successfully writes 10 characters in a row from its interrupt handler, or more accurately if there are still pending interrupts after ten loops through the interrupt handler, it throws up its hand and goes off to sulk in the corner.
Fortunately it’s easy to patch out the 10-loop limit and get functioning serial terminals.
The Survivor
After finding a few missing sectors elsewhere and manually reconstructing some, the result is a fully functioning Xenix 2.2.3 with no known problems. It’s a System V derivative, but with a clear Microsoft influence—for example the compiler emits OMF object files and executables are in Microsoft’s X.out format (essentially a segmented a.out variant).
The uname command in 386 Xenix 2.2.3c
It’s a classic Unix OS, adapted for PCs. It handles at least up to 16 MB RAM, supports virtual consoles, it uses paging, it is fully compatible with existing 16-bit Xenix binaries, but also supports 32-bit applications. It’s a real 32-bit PC operating system.
So what other 386 PC OS has survived to this day? Anything from 1987?
It seems I should search through my old diskettes soon. And for the question marks: Digital Research Concurrent DOS 386 was released in early 1987. Not to forget the 386 version of FlexOS (also from DRI) which was available from late summer 1987. It was widely used in IBM POS 4690 family. Now it’s called Toshiba 4690 OS.
Minix came out in 1987 but it was not targeted to the 386 until later versions.
Another three operating systems that had 386 versions on the market in 1987 are
ix386 though the slightly later versions relabeled Interactive Unix are much easier to find
PC-MOS: again, the initial 386 release seems to be unavailable anywhere but the 1988 version with patches is easy to find
iRMX III: A version that seems to be skipped.
Venix and Coherent both updated to the 386 but I think that didn’t happen until 1990.
Plus Sun showed a 386 beta of SunOS 3 for universities to test the 386i about a year before SunOS 4.01 officially supported the 386.
What I remember is the early 386 Unix derivatives had all the stability of quicksand and the early software to run DOS programs on top was the best marketing material for DesqView ever devised. Not a happy time to be an early adopter.
I already mentioned Interactive and Microport. They had products, but what survived is the question. PC-MOS is something I need to research. Did iRMX III run on PCs?
SunOS 386 does not really qualify here, not a PC OS. But a very interesting product nonetheless!
Love the quicksand anecdote BTW. And I wonder how much of the instability was caused by the hardware, because the early 386s were really rather buggy. That’s something Intel fixed, and the OS writers learned to utilize the hardware better. Microsoft complained that it took them until ’87 to release 386 Xenix because they had to fight all the hardware bugs.
@Richard: during the work on my side of this story (which part 2 is here: https://soylentnews.org/meta/article.pl?sid=17/03/07/1632251), it reminded the worse of UNIXes of the era. A hard crash could destroy the file system fairly easily. I went through a few VMs when Xenix crashed and panicked . Now that we’ve got it mostly put back together, it’s fairly stable but UNIX of the era was not the shining beacon of awesome most people think of it as.
By 1990, iRMX was listing support for IBM AT in addition to Multibus systems. The only online confirmation I can find for it is http://www.drdobbs.com/the-irmx-family-of-operating-systems/184402293 Full details on iRMX support and what year it was implemented is not something I have been able to track down, even back when I had projects that seemed well suited for it.
Bitsavers has a bunch of docs for iRMX III 2.2 from 1995 and that version did run on PCs (with Windows NT even). I’m not sure which was the first version that ran on PCs was but iRMX II.3 for the 286 from 1988 only ran on Intel Multibus machines.
I came across this list of copy protection methods today — it includes one (KBI-19) that has 19 overlapping sectors on a double-density track. It sounds unlikely that the Xenix floppies would have used that sort of copy protection, but it’s one explanation for the multiple sectors.
That’s pretty interesting copy protection! Definitely not what Xenix used, most of the disks are simply tar archive dumps. SCO used software copy protection built around serial numbers and activation keys, the media itself never had any copy protection. But TeleDisk could handle multiple sectors with the same ID (perhaps some PC-based copy protection used that, or some non-PC format) and that’s why it could confuse itself. There is no evidence of overlapping sectors or anything like that, there are simply normal data sectors with several duplicates.
Sadly, TeleDisk was not the best tool for backing up Xenix disks because it’s too clever 🙂
Is this the same dump? It seems to have been made quite recently.
There is also an OMTI and a PS/2 version:
https://groups.google.com/d/msg/comp.unix.xenix/omlTqjMC828/-5YQzk_1dAQJ
Whoa. No, we were working with a different disk set that was made no later than 1996. The one on archive.org is indeed brand new and it is the 386PS (i.e. PS/2) version, the one covered in the article is 386AT (regular AT compatible).
I really wish that thing had shown up a few weeks ago, now we have a 99.98% faithful reconstruction already 🙂
This really makes you wonder about coincidences. Michael’s first post went up on March 6th. The 386PS disk images were uploaded on March 5th. WTF?!
You can find the disks we worked with here for example (though I’m too lazy to check if they only have the raw images or the TeleDisk ones, too). If you can’t find the TeleDisk images but would like to have a look, just let me know.
I think the archive.org set originated here.
Yep, same guy, same disk set (for PS/2 machines). Amazing.
The older release (labeled as 2.2, in fact 2.2.2f) is from February 1988. Except I’m not sure it counts as the oldest surviving 386 PC os because it only runs on PS/2 machines, not PCs! There was a 386 Xenix 2.2.2 release for PC/AT-compatibles as well, available sometime in late ’87. Current whereabouts unknown.
There have been different releases of 2.2.2, a restricted, and a first customer shipment. XENIX 386 2.2.1 was done by Compaq and SCO, so it runs on Compaq 386S or similar machines. I have to look for other OEM’s versions from Altos, ICL or Siemens. You can simply type nothing in the search field of SCO’s knowledge base and select the “Expired Product” of “Xenix” to get dozens of technical articles. A newer wd controller driver (also for 2.2.3) is contained in ftp://ftp.sco.com/pub/SLS/xnx133.Z
A collection of articles from the DiSCOver newsletter (1987/88) can found here: ftp://ftp.sco.com/pub/SLS/xnx114.Z
I was able to establish that 386 Xenix 2.2.1 did exist, but could not find anything closer, except for one mention that it was available in Germany as of October 1987. The c’t archive is unusually quiet, they didn’t seem to be very interested in Unix. Couldn’t find anything specific in InfoWorld either.
The wd1010 driver updated for the WD1007 controller has the same problem with the INITIALIZE PARAMETERS command… in the 2.2.3 version only. I didn’t really check what they actually changed. The 2.3.x disk driver was redone quite a bit and never had that particular problem.
The content from Computerwoche is not much different from Compaq/MS press releases from this time. c’t didn’t cover UNIX topics, there is another magazine from Heise that started in 1988 called “iX”. Besides official SCO publications and the xenix faq the most valuable information can be found in comp.unix.xenix (1987/88) or later biz.sco.announce (1991) newsgroups.
I’m familiar with iX but don’t have an archive (like I have of c’t) 🙂
There is a DVD “iXpressed” from 2004 which contains articles from 1988 to 1993, but not unfortunately not everything. Every issue is scanned more than 50 MB PDF file without OCR. If you’re looking for something specific use the program Heise Register from here: ftp://ftp.heise.de/pub/ct/register/register.htm (register.zip is needed). The first iX issue 11/88 has a review of SCO VP/ix and Microport Merge 386.
I wonder if it was ever considered to add GEM and native 32-bit apps into DRI Concurrent DOS 386. GEM would probably be built into the kernel, with virtual 8086 mode used to run legacy 16-bit GEM apps. It would be far more interesting than DR-DOS.
(DRI was lucky MS screwed OS/2 2.0 so badly they could still sell DR-DOS for years.)
Actually, I wonder why GSX/VDI ended up being considered part of GEM instead of being say standard in all future versions of Concurrent DOS and redistributable for CP/M-86 and MS-DOS. DRI would really want to encourage all apps (not just 32-bit apps) to use GSX/VDI for several reasons, including the fact that they are far easier to remote.