Another rather interesting software artifact surfaced just recently, after more than 25 years since its release: Windows 3.0 Debug Release 1.14 (further referred to as DR 1.14) from February 1989.
This was an alpha version only provided to select ISVs under a non-disclosure agreement as a preview of the future Windows 3.0 product—which turned into a runaway success and made Microsoft king of the software industry. It was first demonstrated at the annual Microsoft Systems Software Forum in February 1989.
The final Windows 3.0 was released in May 1990, more than a year after the DR 1.14 alpha release. Not surprisingly, the released product barely resembles the alpha release; nevertheless, the DR 1.14 release was a quantum leap which convinced Microsoft to split with IBM, go it alone, and take over the multi-billion retail software industry.
What was so special about the DR 1.14 alpha? It ran Windows applications in protected mode, with direct access to many megabytes of memory. Here it may be necessary to go back to the architecture of earlier Windows versions.
Windows 2.x and Windows/386
In 1987, Microsoft released Windows/386 for the Compaq Deskpro 386, followed by the real-mode Windows 2.03. This was a successor to the original Windows 1.x, first released in 1985 after two years of delays.
Normal Windows 2.x, whether called just Windows 2.03 or Windows/286 (2.1, 2.11) was a 16-bit real-mode product, a direct successor to Windows 1.x. Windows applications were restricted by the 640 KB memory barrier, although they could use EMS to gain access to further memory—but only a small window of EMS could be mapped into the CPU’s address space at any one time. That made memory management highly complex and error-prone. Windows 2.03 and Windows/286 could run on any IBM PC, PC/XT, or compatible system. The only minor advantage Windows/286 took of PC/AT compatibles was the addition of 64 KB of high memory.
Windows/386 was Windows 2.x plus a VMM, or a Virtual Machine Monitor. Windows/386 could run several DOS sessions with pre-emptive multitasking, plus one Windows session. While Windows/386 did quite a lot for DOS applications, it did very little for Windows programs. Windows/386 could emulate EMS memory, but Windows applications were still executed as real-mode code, with the same 640 KB memory limitation and EMS complexity. And of course Windows/386 required a 386 machine, which severely limited its potential market in the late 1980s. It also had to fight stiff competition like Quarterdeck DESQview.
Windows 3.0 DR 1.14 Alpha
The beginning of Windows 3.0 was a little skunkworks project of David Weise and Murray Sargent started in June 1988 and presented to Steve Ballmer sometime in late summer 1988. It began as a hack, and DR 1.14 clearly reflects that.
What the February 1989 alpha release did was seemingly not much. It was essentially Windows/386, except it ran the Windows core (KERNEL/USER/GDI) and Windows applications in protected mode.
But that was in fact a big deal, because it removed the highly constraining 640 KB memory barrier. On a (very high-end) system with 4 MB RAM, Windows applications could directly access several megabytes of memory. Windows applications were still segmented 16-bit code, but now ran in protected mode with no need for complex EMS memory paging, and with lots more of them fitting into the system’s memory than before.
The beauty of the solution was that many existing Windows 2.x applications could run in protected mode without any changes whatsoever.
A Closer Look
The DR 1.14 release was obviously hastily thrown together as a technical demonstration, a proof of concept, but not a product. It came on two high-density 5¼” floppies. The setup utility was a simple batch file which copied the floppy contents to a hard disk directory.
There was no device selection—Windows was pre-configured to use an EGA color display and no other drivers were included. There was just enough to get a bare system running, but there were no applets on the disks (Control Panel, Paint, Clock, Reversi, etc.).
However—and this was the strength of this build—most of the applets shipped with Windows 2.x ran unmodified. The segmented memory model of Windows 1.x/2.x was such that it was easy to move to protected mode, although that wasn’t what it had been designed for. Simple, cleanly written Windows 2.x code ran in protected mode unchanged. More complex or dirty code required modifications, often not extensive.
Overall the DR 1.14 release looked very much like Windows 2.1 and did not really resemble Windows 3.0 at all. Microsoft didn’t even bother to consistently change the version numbering: While the debug build marker read “Windows v3.0 Debug Release 1.14”, the About box said “Version 2.1”:
The components of DR 1.14 very much resembled Windows/386 2.1 (1988). There was WIN386.EXE, USER.EXE, GDI.EXE, DISPLAY.DRV, KEYBOARD.DRV, and other familiar modules. But instead of KERNEL.EXE there was PKERNEL.EXE—clearly an allusion to the kernel running in protected mode.
Once again let’s demonstrate the difference between Windows 2.x and 3.0. First, Windows 2.03 with several applets loaded:
But… and here’s the very big but… all that may not help the user:
Even with megabytes of free memory, DR 1.14 might not be able to start new applications. This may be the same problem that plagued Windows 3.x—numerous internal structures limited by the 16-bit architecture could prevent new applications from being started (or running correctly) even when there was a lot of free memory.
What Was in DR 1.14 and What Wasn’t
It’s useful to go over a list of features that were or weren’t included in DR 1.14.
There was no way to run Windows in real mode. Although WIN86.COM was included, it exited immediately. PKERNEL.EXE was not prepared to run in real mode at any rate (more about that below).
There was no standard mode either, because there was no DOSX. There was only the equivalent of the future Enhanced 386 mode of Windows 3.0 (and a 386 system was naturally required).
The user interface was obviously that of Windows 2.1 and looked nothing like Windows 3.0 (see screenshots above).
The ability to run DOS sessions was missing (no WINOLDAP.MOD).
On the other hand, there was WDEB386.EXE, Microsoft’s system-level debugger for Windows/386. WDEB386 was later used for Windows 3.x as well as Windows 95 and 98, although most developers probably used Soft-ICE at that point (a far superior solution).
Microsoft also helpfully included symbols for the core components—WIN386, PKERNEL, USER, GDI, and the SYSTEM/DISPLAY/KEYBOARD/MOUSE/SOUND drivers.
There was no documentation included on the disks and no headers or libraries. Those may have been shipped separately, but it’s quite likely that DR 1.14 was simply meant as a showcase and as an aid to help ISVs make their existing Windows 2.x code compatible with protected mode. It should be kept in mind that Windows 3.0 continued to support real mode operation, and a well-written Windows 3.0 application should run in either real or protected mode.
The KERNEL exports resembled Windows 2.x, but there were a few crucial additions such as AllocSelector and FreeSelector, AllocDSToCSAlias and AllocCSToDSAlias, __LDTSELECTOR (which promoted all sorts of dirty programming practices), or the famous PrestoChangoSelector.
Running DR 1.14 in a VM
Not surprisingly, running such an unfinished product in a VM or on remotely modern hardware is fraught with difficulties.
The first hurdle is that Windows 3.0 DR 1.14 either refuses to load (“not enough memory”) or crashes miserably on a system with 16 MB RAM or more. That’s easy to fix in a VM, though may be harder in a physical system.
The second hurdle is the DOS version. DR 1.14 refuses outright to run on DOS 5.0 or later and complains of unsupported DOS version. With MS-DOS 3.30, DR 1.14 does start up but never brings up the MS-DOS Executive.
Windows 3.0 DR 1.14 does work on Compaq DOS 3.31 (likely in widespread use at Microsoft at the time), and it also works on MS-DOS 4.01 (the then-current MS-DOS release).
One additional caveat is that DR 1.14 misbehaves very badly when the FILES statement in CONFIG.SYS doesn’t provide enough file handles. FILES=30 appears to be a good amount, but with fewer file handles DR 1.14 may not start at all or applications may randomly crash. Yet another sign of a very unfinished product.
With a suitable amount of memory (perhaps 4, 8, or 12 MB) and the right DOS version and configuration in place, DR 1.14 should come up (assuming one followed the HIMEM.SYS instructions) when started via WIN386.EXE:
Being a debug release, this Windows 3.0 alpha was of course primarily meant for debugging. The supplied D.BAT will just hang on most systems. This one is Intel’s fault and the problem is documented for WDEB386.EXE shipped with the Windows 3.1 DDK. The same instructions accessing TR registers need to be patched out for the WDEB386 executable shipped with DR 1.14.
The issue is that Intel entirely removed those instructions (which existed in 386 and 486 CPUs) from the Pentium and later CPUs, so the debugger triggers invalid opcode exceptions. Fortunately patching out the instructions is harmless.
Once WDEB386.EXE is patched, D.BAT brings up Windows. The serial console (COM1) starts spewing all sorts of interesting stuff:
Map linked (KERNEL) Map linker (USER) Map linked (DISPLAY) Map linked (GDI) WDeb386 - Windows/386 Kernel Debugger v1.62 27.Jan.89  Win386!DATA(0001)=0028 Win386!DATA(0002)=0030 stop tracing VM break point located at 000F00BC in the system ROM VHIRQD=ON Ctrl+Alt+M is the focus hot key INITIAL REQUEST FOR IRQ 04 (60021FFC) VAD INFO: PS/2 type mouse detected Alt+~ is the focus hot key VDD control block offset of 00000600 VINT33 INFO: No global mouse installed WARNING: Device failed to initialize (DDB = 60022FF4) VMD installed Ctrl+Alt+Del reboot handler VND INFO: Network not installed WARNING: Device failed to initialize (DDB = 60021C60) VNETBIOS VCD INFO: COM 0001 exists VCD INFO: COM 0002 does not exist installed Ctrl+Alt+SysReq break handler Base count = 00002EDB 75% of this is 00002324 Desired moved down to 00000066 KERNEL!IGROUP=017D KERNEL!_NRESTEXT=0185 SYSTEM!DATA(0001)=01C5 KEYBOARD!DATA(0001)=01E5 KEYBOARD!DATA(0003)=01F5
If applications crash (and they will), WDEB386 can be used for diagnosing the problems.
On normal “unbound” development versions of Windows, running KERNEL.EXE directly should start Windows. But PKERNEL.EXE just hangs instead, for a somewhat obscure reason. It invokes INT 41h which is of course a pointer to the disk parameter table and not executable code… except that INT 41h used as a debugger interface (outputting debug strings etc.) in protected mode. If INT 41h is invoked in real mode, nothing good will happen.
As evidenced in the screenshots, DR 1.14 can run most applets shipped with Windows 2.x and the Windows 2.x SDK. One notable exception is Write. Larger applications, such as Excel 2.0, are highly unlikely to work, although only minor modifications might be needed.
The jump from the Windows 3.0 Debug Release 1.14 to the final Windows 3.0 is fascinating to consider. This is a great example of the huge difference between a technology demonstration and a polished product.
It is interesting (and heartening) how old, long lost and unavailable software packages keep turning up. Just as a quick reminder: Multitasking MS-DOS 4.0 from 1986, the original Compaq EMM aka CEMM from 1986, the original Windows/386 2.01 from 1987, and now this.
What else is lurking out there? Probably quite a lot…maybe the original WordStar that caused all the A20 gate hell? Microsoft OS/2 2.0 SDKs? Beta versions of Windows 2.x?
Let’s hope the surviving software is found, and the disks are imaged and documentation scanned before they turn to dust or end up in a landfill.
OS/2 for 386 will not be out this year, ComputerWorld, Feb 27, 1989, page 10