Here’s a preview of something I’ve been slowly working on, bit by bit:
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.
Continue readingAs promised, here is the source code for the Windows 9x VirtualBox display minidriver. For discussion of the source code, see the included readdev.txt file.
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:
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):
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:
It is not difficult to see that WordSet is really WordStar, superficially renamed and with user visible text translated to Czech.
Continue readingThe 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.
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.
Continue readingA 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 released NT 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.
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.
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…
Continue readingIt was recently pointed out to me that a simple “hello world” style application built with Open Watcom C/C++ 1.9 does not run on Win32s version 1.30, even though the same executable runs just fine on Windows NT 3.51, Windows 95, or Windows 10.
More specifically, the program crashes rather early on Win32s. With the help of map files and source code, I established that the crash occurs in an internal function called __setenvp, which tries to dereference a null pointer stored in an internal variable _RWD_Envptr.
The _RWD_Envptr variable is filled in by the GetEnvironmentStrings API in the C runtime startup code. The GetEnvironmentStrings API call ends up importing GetEnvironmentStringsA from KERNEL32.DLL. And clearly GetEnvironmentStringsA is failing on Win32s, although it works just fine on NT and Win9x.
Further probing revealed that the GetEnvironmentStrings API has curious history. On Windows NT 3.1, there was only GetEnvironmentStrings (no A or W suffix). On all later Win32 implementations, starting with NT 3.5, there’s GetEnvironmentStringsA and GetEnvironmentStringsW, as well as FreeEnvironmentStringsA and FreeEnvironmentStringsW.
On NT 3.1, there was no FreeEnvironmentStrings, presumably because GetEnvironmentStrings returned a pointer to existing memory that couldn’t be freed (and would be freed at process termination anyway). On NT 3.5, GetEnvironmentStringsA converts the strings provided by GetEnvironmentStringsW and allocates memory for the converted strings, so there is something to free.
A quick experiment with Microsoft Visual Studio 4.0 showed that a test application does run on Win32s; reading MSVC 4.0 runtime source code also revealed that Microsoft calls GetEnvironmentStringsA and immediately terminates the process if GetEnvironmentStringsA fails. So… how can that work on Win32s?
When I wrote about the pre-release NetWare Requester for OS/2, the oldest archived officially released NetWare OS/2 Requester was version 1.2 from 1990. In the meantime, version 1.1 of the requester showed up, although I only became aware of that very recently.
Technically the 1.1 Requester does not appear to be vastly different from the 1.0 pre-release. Which is unsurprising, because the OS/2 1.1 kernel was not that different from OS/2 1.0; the big news in OS/2 1.1 was the Presentation Manager GUI, but that was not something Novell cared about at the time.
The Requester was shipped on three disks, labeled SYSTEM, PUBLIC-1, and PUBLIC-2. As the names suggest, the PUBLIC-1 and PUBLIC-2 disks were meant to be copied on the server, whie the SYSTEM disk needed to be installed on each OS/2 workstation.
Unlike the pre-release, the 1.1 Requester came with an actual installer, although what it did was a little underwhelming.
The installer copies files but does not actually change CONFIG.SYS at all. Instead, Novell provided a template which can be appended to the existing CONFIG.SYS and edited to enable the desired components (SPX, named pipe support, NetBIOS).
The user also has to pick the right driver. Novell provided a good selection of drivers, for Ethernet (Novell NE1000, NE2000, 3Com 3C501, 3C503, 3C505) as well as IBM PC Network, Token Ring, and Novell RX Net.
Continue reading