(This is a guest post by Antoni Sawicki aka Tenox)
Project Monterey was an attempt to unify the fragmented Unix market of the 90s in to a single, cross vendor Unix OS that would run on the upcoming Intel Itanium (and others) CPU. The main collaborators were: IBM, who brought its AIX, SCO brought UnixWare, HP was supposed to bring parts of HP-UX and SequentDYNIX/ptx. Ironically the project shared fate of the Itanium CPU—it totally failed. In the end Linux took spot of the “single Unix OS”. IBM donated AIX pieces to Linux instead and the main legacy of Project Monterey was the famous SCO vs IBM lawsuit.
IBM did however produce AIX version for the Itanium architecture! According to Wikipedia, some 30+ licenses were sold in 2001-2002. For years a dedicated group of individuals was trying to locate a copy of the legendary OS. It seemed that the OS was lost forever…
This is a guest post written by Marko Štamcar from the Slovenian Computer Museum in Ljubljana. Additional context and commentary from the OS/2 Museum can be found at the end of the article.
Slovenia being a tiny country with a population of just 2 million, IBM OS/2 Warp 4 was one of the few non-Microsoft operating systems to be localized to Slovenian in the mid-90s and a big deal for the local IT community back then. But nearly 3 decades later, when OS/2 disappeared from the last ATMs in the country, the even rarer Slovenian version was as good as completely gone. Or was it?
The Slovenian Computer Museum
Cue the Slovenian Computer Museum and our software heritage/conservancy activities. I have been part of the museum for the last 5 years and am the head of the laboratory (responsible for getting old machines to work for them to be shown off) and vice president of our non-profit organization. Our museum was founded in 2004 as part of the local hackerspace Kiberpipa/Cyberpipe but has since outgrown its humble beginnings and is now located in a dedicated space with 700 square meters of useful room on three levels dedicated to museum storage, exhibition and event space, and two classrooms. (More info on the museum’s website.)
Here’s a preview of something I’ve been slowly working on, bit by bit:
Windows 1.04 Reversi
That screenshot surely looks a little funny. That’s because it is Windows 1.04 running with a heavily modified 256-color Windows 3.x display driver, using resources from a Windows 2.0 VGA driver.
This is mostly the same driver, running real-mode Windows 3.0:
A few days ago I spent far too much time debugging a largish piece of 16-bit Windows code written in assembler. I found a scenario where (fortunately fairly reproducibly) Windows crashed because the internal state of a DLL got corrupted.
I could see that the state made no sense and a supposedly small rectangle was suddenly tens of thousands of pixels large, causing segment overruns when it was copied. The internal state of the DLL was corrupted, and it very much looked like a buffer overflow.
I added size checks to make sure nearby buffers weren’t being overwritten, but the checks never fired. Or rather they only fired when the state was already corrupted.
Then I tried reshuffling the data so that the buffer which I suspected of overflowing was at the very end of the data segment, hoping that it would cause a protection fault when the buffer overrun happened. But the fault never happened, and the state was still getting corrupted.
The code was developed on a Windows 10 host system. For extra credit, I attempted to build the minidriver on Windows 9x. Ideally with source code control… but is that even possible?
I could not find any clear information on whether Mercurial ever worked on Windows 9x. After a longish software archaeology session, I concluded that it did, at least somewhat. Here’s the proof:
Developing with Mercurial on Windows 98
I used a Mercurial 1.1.2 installer downloaded from here. As far as I can tell, none of the downloads from the official site (Mercurial 1.4 and later) work on Win9x—Mercurial installs without complaints, but fails to do anything useful, possibly because of Python incompatibility with Windows 9x.
But Mercurial 1.1.2 works, least on Windows 98 SE and Windows Me. It fails to clone over HTTP on plain Windows 95 because the Python socket module won’t load. There may be a way to upgrade the Windows 95 socket support but that is of limited interest to me given that Windows 98 SE works without tweaking. I have not tried to figure out if and how well other Mercurial versions work, since 1.1.2 did the job I needed.
With the source code on a Windows 98 machine, it’s no problem building it with the Open Watcom C/C++ 1.9 compiler, it is just a question of running wmake. Happy hacking!
A kind reader from a land formerly beyond the Iron Curtain recently supplied the OS/2 Museum with a curious word processor that calls itself WordSet. The files unfortunately lost their original timestamps quite some time ago, but it is apparent that this editor was released in the late 1980s, with copyright messages in different files referring to 1986 and 1988.
The editor runs on DOS, but there appears to have been a CP/M variant available as well, as evidenced by this manual (photo from an auction):
WordSet for CP/M manual
When the DOS version of WordSet (WS.COM) is started, the user is greeted by a screen that may look more than a little familiar:
WordSet main menu
It is not difficult to see that WordSet is really WordStar, superficially renamed and with user visible text translated to Czech.
The OS/2 Museum has made available the first version of a display driver disk for Windows 9x running on VirtualBox. The driver uses a linear framebuffer and supports 8/16/24/32bpp modes with resolutions up to 1920×1200 pixels (see more below). The driver is not accelerated but tends to be very speedy on modern hardware.
Windows 95 in a usable resolution
I’d like to say that it was easy to adapt the existing Windows NT video miniport driver for Windows 9x… but of course it wasn’t. The Windows 9x display driver model is completely different and has nothing in common with NT. The Windows 9x display driver has much more in common with Windows 3.1 (and 3.0 and 2.x) drivers, and it has clearly directly evolved from those older drivers.
So what makes it a “minidriver”? A Windows 2.x/3.x display driver has to implement a very significant chunk of GDI. Bit blits, lines, text output. There is a lot of cases to handle and a great deal of complexity. To give some sense of the complexity, the Windows 3.1 DDK sample driver for Video 7 cards is about 1.6 MB (circa 60,000 lines) of assembler source code. And that’s just for 8bpp displays.
A rater nice Compaq EGA Tech Ref recently turned up on archive.org, under the title COMPAQ Enhanced Color Graphics Board Technical Reference Guide. It’s from December 1986, relatively late in EGA’s life (given that it was about to be obsoleted by the VGA in just a few months), and it is rather good.
The Compaq Tech Ref is significantly more detailed and in-depth than the IBM Tech Ref. On the other hand, IBM supplied a BIOS listing which is very valuable, both when interfacing with the BIOS itself and when trying to understand certain details of the hardware. Compaq documented the BIOS well and provided nice examples, but that’s not the same as the actual source code. As is often the case, looking at both references is best.
I’ve finally managed to update the previously releasedNT video miniport. The reason for the update was indirect, hacking up the video “hardware” access code to support other environments. That led me to separate the generic mode set code from the mode table oriented logic. Since the NT miniport does not need the mode tables, the resulting boxvideo.sys is now about 1 KB smaller without losing any functionality.
VirtualBox NT video miniport driver, now at version 1.6
As before, the miniport should run on any x86 version of NT from 3.1 up to 7, with the caveat that for NT 3.x, the user has to supply FRAMEBUF.DLL from the NT installation media (see included README file). Also for NT 3.1 only, the installation and mode selection process is different from later versions.
At some previous point, so long ago that I don’t even remember, I expanded the list of supported modes to go up to 5,120×2,880 pixels. This is not extensively tested because I don’t have such a large display, but at first glance it does not appear to be completely broken.
Get the updated driver here. The source code can be viewed here.
As previously mentioned on this site, the IDENTIFY DRIVE command in the ATA specification almost certainly first appeared in ESDI controllers supplied to Compaq by Western Digital.
Since I have now finally secured a working ESDI hard disk, I could do some probing. Unfortunately I don’t have access to a WD1005 ESDI controller that should be extremely close to what Compaq used circa 1986, but I have two of its successors, WD1007A and WD1007V. A spare WD1005 anyone?
My WD1007A (1987) clearly came out of a Compaq machine and it is a rather interesting piece of hardware. It is a hard disk controller only, with no floppy support. It also has no BIOS (though other models did, and the PCB clearly has room for it).
The newer WD1007V-SE2 (1989) might be a retail model; it includes a floppy controller and a BIOS, although the BIOS can be disabled since it wasn’t necessary in many PC/AT compatibles.
WD1007A and WD1007V ESDI controllers
Now, what’s very interesting about these WD ESDI controllers is that from a software perspective, they would be very difficult to distinguish from an IDE drive. They support the exact same registers and commands as a standard PC/AT controller, but additionally also implement the IDENTIFY DRIVE command. At least in the case of the WD1007V, the controller also supports READ/WRITE MULTIPLE commands, READ/WRITE BUFFER commands, and probably some form of cache control. In other words, the WD1007V even acts like a not so basic IDE drive.
Now back to IDENTIFY DRIVE. That would have been the big difference between a controller for ST506 style MFM or RLL drives and an AT-compatible ESDI controller. ST506 (or ST412, if you’re Seagate) drives simply have no mechanism to report their characteristics to the controller. But ESDI drives do. Anyway, let’s look at the details…
