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”:
Whereas 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.
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:
And now DR 1.14 with exactly the same applets:
The 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:
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 [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
@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.
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
@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.
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.
Glad to hear you got it working!
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
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.
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.
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.
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.
Of course, my point is that the decision to go for Windows over OS/2 was a bad decision in the first place.
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.
“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.
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
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.
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.
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.
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.
Yea, there was little point in a protected mode OS if you could not afford more than 640K of RAM.
windows 386 did little better OS/2 1.0 due to dos support
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
“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.
From the fact that it’s EGA only and the fact that Microsoft apparently made great use of ’em around the period, it’s probably safe to say the DeskPro 386 (or 386/20) was the target machine for this build. It hangs the machine hard when ran on a PS/2 8580 (386/20) when configured to it’s liking at any rate.
From what I heard, basically as soon as the DeskPro 386 showed up, Microsoft developers started using them en masse because it was by far the fastest PC they could get at the time. They definitely worked pretty closely with Compaq, and we know that Windows/386 (version 2.01) was even initially released for the DeskPro 386.
I wonder why the Windows 3.0 team took such a conservative approach to protected mode Windows. This meant that even Windows 3.1 WinHelp (can be installed on Windows 3.0) and of course almost all Windows 3.0 drivers have to be written for real mode.
Thinking about it, I think Wes Cherry only got an XT for her work on Solitaire in Windows 3.0.
Well, Windows 3.0 applications has to be able to run in real mode due to Microsoft decided to not drop the real mode support until Windows 3.1
In 1990 when Windows 3.0 were released there were still loads of XT class machines in use.
What I don’t know is what the typical machines running windows were at the time though. Maybe there were only a small number of users actually using windows on a XT class machine?
I assume there wasn’t any real reason to rewrite Winhelp.exe when Windows 3.1 were released.
Her? You mean his?
Yes, there were millions of XTs out there in 1990. The question is how many of them were actually capable of running Windows 3.0 in any kind of useful fashion. If the machine had no hard disk, forget it. If the machine didn’t have at least an EGA, forget it. I never tried Windows 3.0 on an XT myself but from what I heard, it was not a pleasant experience.
A better question is perhaps whether Microsoft needed to keep real mode support for some other reason than supporting XTs. Incompatible memory managers? Running in OS/2? Stuff like that.
Thinking about it, I wonder why MS did not have any 286 standard mode debuggers other than CVW with Windows 3.0. Wes Cherry should ideally be debugging Solitaire in standard mode not just real mode for obvious reasons, but a 386 would probably have been too expensive.
It is worth noting that there was a DRAM shortage in 1988 though and even in 1989 it took some time for DRAM prices to fall. (You can’t even boot standard mode Windows with only 640K as HIMEM.SYS can’t be loaded.)
And yes my point is that the Windows 3.0 team did not seem to realize how quickly real mode Windows would become obsolete.
Before Windows 3.0 actually started to sell, no-one knew that Windows would be a success.
I’m not sure about what Microsofts intensions were with Windows 1.x and 2.x. Perhaps just make people buy a PC rather than a MAC thinking that they could get Windows if they wanted a GUI. Perhaps also just to make sure that some GUI making skills existed in-house.
Actually, I just found out that WDEB386 does work on a true 286 in standard mode in the final version of Windows 3.0.
I think Real mode Windows was already causing problems for at least a few MS products even before Windows 3.0 was released. For example:
http://web.archive.org/web/20080920041025/http://blogs.msdn.com/oldnewthing/archive/2008/09/17/8954572.aspx#8957565
According to https://blogs.msdn.microsoft.com/murrays/2006/12/07/saving-windows-from-the-os2-bulldozer/ : “To get the ball rolling, Murray built the DOS extender into SST, with the idea that it would be separated out later, something Murray’s colleague, Gene Apperson, did, in fact do.”
At the same time (Summer ’89) Bill Gates was publicly saying that DOS extenders are no good. Though he only meant DOS extenders without a GUI.
Given http://antitrust.slated.org/www.iowaconsumercase.org/011607/0000/PX00111.pdf I wonder if there was any copies of Windows/286 3.0 Debug Releases that ever made it outside of MS.
http://antitrust.slated.org/www.iowaconsumercase.org/011607/0000/PX00236.pdf even mentions concerns over Windows 2.1 inventory.
Thinking about it, I wonder why Windows 3.0 did not introduce functions in KERNEL to properly disable/enable interrupts for use in drivers. Technically DPMI clients should use Int 31h functions to enable/disable interrupts, but this would not work on real mode Windows.