Windows 3.0 DR 1.14, February 1989

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.

Window 3.0 DR AppletsThis 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”:

Windows 3.0 DR AboutWhereas Windows 3.0, shown below, was known for its attractive looks (at least by 1990 standards), the same could not be said of DR 1.14.

Windows 3.0 DesktopThe 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:

win30-dr-win2-lowmemAnd now DR 1.14 with exactly the same applets:

Windows 3.0 DR Reduced MemoryThe amount of available memory (1,905K, on a 4 MB system) is still much bigger than what the older version started out with (356K)! That’s exactly why this alpha release was a big deal.

But… and here’s the very big but… all that may not help the user:

Windows 3.0 DR Out of MemoryEven 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:

Windows 3.0 DR DesktopBeing 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
[80386]
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.

Thoughts

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.

References

OS/2 for 386 will not be out this year, ComputerWorld, Feb 27, 1989, page 10

This entry was posted in 386, Microsoft, PC history, Windows. Bookmark the permalink.

72 Responses to Windows 3.0 DR 1.14, February 1989

  1. Richard Wells says:

    @JoshuaRudd

    Had there been need for interprocess communication of DOS applications under Windows 3.0, it can be done through WinOldAp’s use of DDE. Would be different from pipes but still a workable solution. Few apps bothered with WinOldAp let alone exploring its full potential. Wasn’t just a Windows problem; Topview and the Desqview enhancements, and Vmix and the multitude of DRI DOS multitasking support APIs were all basically ignored by DOS application developers.

    Multithreading was a lack but the various DOS based products that offered a form of multithreading got little use. Very hard work to create code that could both run on normal single threaded DOS and a full fledged MT DOS. Unless MS could completely replace all DOS versions with MT DOS, only a handful of vertical applications would bother.

    There is an additional problem in that MT DOS would have broken many existing drivers and possibly some applications. The more I look at it the more I am convinced that MT DOS became untenable once MS decided on a different OS of the future. The last thing MS could use would be another incompatible OS that requires upgrading applications.

    I admit I am seduced enough by the idea of clean OS design to wonder what would have happened if Win9x had been redesigned splitting off much of the generic kernel elements into a protected mode MT DOS and freeing the GUI from having to make end runs around the real mode portion of the system. I just doubt it would ever work well enough to justify the development cost.

  2. jack says:

    hey guys i got windows 3.00.14 alpha to work on VirtualBox, and i follow instructions
    on OS/2 Museum then i’am change ram to 12 Megabyte of ram and used ms-dos 4.01
    as the base Operating system. if you follow these instruction it will work on VirtualBox or Virtual PC

    thank you OS/2 Museum

  3. Yuhong Bao says:

    @Richard Wells: Yea, OS/2 2.x would still probably have been a much better solution, and remember that the Win9x dependence on real mode DOS helped Caldera continue the lawsuit.

  4. Michal Necasek says:

    I’m convinced that multitasking MS-DOS 4.0 withered on the vine because it was too limited by real mode, and the improved protected-mode version was called OS/2.

    There all those revisionists saying how MS/IBM should have gone straight for the 386, but those people clearly never saw the errata sheets for the old 386 Ax/Bx steppings. The thing was just incredibly buggy and a paged protected mode OS was a fantasy.

  5. Michal Necasek says:

    Glad to hear you got it working!

  6. jack says:

    Windows 95 not based dos, but it is dos and
    windows hybrid, when windows used virtual real mode
    or virtual 8086 mode is all dos, WIN/32 is all windows.

    OS/2 better feature than Windows 95 because OS/2 is real
    32 bit OS, OS/2 failed because IBM could not sell in market

  7. dosfan says:

    Besides the early steppings of the 386 being buggy, OS/2 was originally developed before there was even a 386 system on the market (the first 386 PC, the Compaq Deskpro/386 shipped in September 1986). Even when OS/2 did ship in December 1987 there were few 386 systems out there and they were very expensive so ignoring the large installed base of 286 systems would have been crazy. In the end it wouldn’t have made a difference anyway. Once the relationship between IBM and Microsoft fell apart and Microsoft decided to push Windows it was over for OS/2 since IBM never truly understood the consumer market and didn’t realize that without a couple of major apps, developer support and a lower cost OS/2 wouldn’t be successful.

  8. Michal Necasek says:

    Actually I would say that IBM realized some of that (see their support for Lotus or Borland) but was not very effective. The free emx+gcc compiler IMO greatly helped OS/2, but it was limited. I think you’re right that IBM either didn’t understand that they needed to more or less give away OS/2 for a while to get a critical mass, or if they understood that, they didn’t do it anyway. The fact that MS had the OEM market sewn up was a big problem too.

    I also strongly suspect that selling to and supporting individual users was something was neither good at nor interested in.

  9. Michal Necasek says:

    And yes, a 386-only mass-market OS made zero sense before 1990, and even then it was questionable. See how quickly NT took off, and that was another couple of years later. Before 1987 there were hardly any 386s at all, and it took years before the percentage of 32-bit systems was high enough to sustain a general-purpose OS.

  10. Richard Wells says:

    The flawed 386 chips are not important to the direction of OS/2. IBM didn’t ship any and Intel offered free replacement of the limited quantity that had been sold. They made as much impact as Tandy flooding the market with 286s incapable of using extended memory: none. IBM’s reluctance to sell the 386 at all because it attacked the AS/400 market was the issue.

    The argument for jumping OS/2 up to 386 was that OS/2 wouldn’t have much software support until 1990. In 1990, early 5170s would be scheduled for replacement. OS/2 would have required about $1,000 to upgrade a 5170 with expansion card and RAM and another $1,000 to upgrade video, or the company could purchase a slightly faster 286, or purchase a full 386 with major performance gains. Penny pinching companies were unlikely to pay $300 to get OS/2 so the computers that would get OS/2 would be brand new 386s.

    My own experience was the 286 was a smidge too slow to handle the full range of demands OS/2 could entail. I had to make some compromises to get a text-to-speech database system barely functioning on a 5170 with OS/2 1.o. Unfortunately, the client only wanted IBM hardware at the time and a lack of 9-track controllers on Micro-Channel required the use of a 5170. A year later, when the client switched to Compaq, development would have been much easier.

  11. Yuhong Bao says:

    Of course, my point is that the decision to go for Windows over OS/2 was a bad decision in the first place.

  12. dosfan says:

    The flawed 386 chips made little difference to OS/2 but this idea that OS/2 should have started out as a 32-bit OS is completely ridiculous. Development of OS/2 began in 1985 and it was released to developers shortly after the April 2, 1987 PS/2 and OS/2 announcement. At that time pretty much the only 386 PC available was the Compaq Deskpro/386. Even IBM’s own 386 system, the PS/2 Model 80 came out a few months later. Had OS/2 targeted the 386 at that time it would have died quicker than it did as there was simply no installed base of 386 systems. By the time that 386 systems started gaining significant market (1990) share 486 systems were already starting to appear so at that point it made sense to make OS/2 a 32-bit OS but not before.

    As for the decision to go with Windows over OS/2, history says that was clearly the right move for Microsoft.

  13. Yuhong Bao says:

    “IBM didn’t ship any and Intel offered free replacement of the limited quantity that had been sold. ”
    I think you are referring to the 32-bit multiply bug only.

  14. jack says:

    When OS/2 came out 1987 it was limited to 286
    protection mode made thing worse.
    Intel made 386 in 1985 where was few PC 386 on market
    and also made thing more worse for OS/2.
    In 1987 microsoft start show little flavor for windows in
    form windows/286 and windows/386.
    Because did its first time the windows did better then was
    people expecting to do ex: excel, word, other apps and market.
    But IBM wanted microsoft to Cancelled windows, microsoft said no
    soon after that windows start growing in market

  15. Richard Wells says:

    The case (at the time) for jumping OS/2 development straight to the 386 can be seen in Charles Petzold’s PC Magazine column of Jan. 16, 1990.

    A lack of time machines means that 16-bit OS/2 would exist but future work would have been reduced to maintenance and the focus shifted to getting the OS/2 2.0 beta into a releasable state by late 1990. Would Virtual DOS Machines plus the small number of 16-bit OS/2 applications and promises that this time the new 32-bit API will pay off have proved enough to kickstart sales and keep developers from canceling OS/2 projects? I can’t know. Instead, IBM doubled down of 16-bit OS/2 polishing up 1.3 and delaying OS/2 2.0 by about 2 years which ended OS/2’s chances of becoming the major OS.

  16. Yuhong Bao says:

    Well, if MS continued to work with IBM on OS/2 2.0, I think late 1991 would have been reasonable as a release date, which would also match up with the yearly release cycle. Remember that the famous AMD Am386-40 for example was released in early 1991.

  17. Michal Necasek says:

    Probably a good year of the delay was caused by Microsoft abandoning OS/2. Some of that could probably be blamed by IBM, but it was not IBM’s decision.

    Another factor worth mentioning was the DRAM price explosion circa 1988. Everyone complained how horribly expensive memory was for OS/2 1.x… and a 32-bit OS would have made that even worse.

  18. Michal Necasek says:

    From what little I’ve seen I agree that a PC/AT was not really powerful enough for OS/2. But what I think is very important is that MS/IBM could develop the OS on 286s and have it ready in 1987. Targeting 386s would have pushed the schedule back by several years, opening a window for a potential competitor (which I’m sure Microsoft, ever paranoid, was very aware of).

    Of course we have the benefit of hindsight, something MS/IBM didn’t have in 1985-86.

  19. Yuhong Bao says:

    Yea, there was little point in a protected mode OS if you could not afford more than 640K of RAM.

  20. jack says:

    windows 386 did little better OS/2 1.0 due to dos support

  21. jack says:

    Windows 2.0 is not a flop, because windows 2.0 was better
    than windows 1.0.
    Windows 2.0 has better feature than OS/2 because OS/2
    was beta stage when windows 2.0 came out 1987.
    IBM also shape windows 2.0 design in today talk is
    windows 3.0 look.
    Also Microsoft word and Microsoft excel came out in
    windows 2.0 and third party apps

  22. Yuhong Bao says:

    “Another factor worth mentioning was the DRAM price explosion circa 1988. ”
    I read that DRAM prices fell ten fold between 1984 and 1985. I wonder if DRAM demand would have increased much if MS targeted multitasking DOS 4.0 at protected mode and released it in 1985.

Leave a Reply

Your email address will not be published. Required fields are marked *