When Windows 3.0 came out in 1990, the press loved it and users bought it in droves. Unfortunately, technically it was at best a step sideways, and Windows 3.0 was the cause of many sleepless nights for application developers. Even though Windows 3.0 in Enhanced mode took advantage of 386 features, those did little for Windows applications. While Windows 3.0 implemented DPMI and enabled 32-bit DOS extended programs to run alongside Windows, the Windows API itself was firmly rooted in 16-bit past and was of little help to would-be 32-bit Windows application developers.
In early 1991, Microsoft started making noise about Windows NT and Win32. However, the common knowledge at the time was that NT “might not ship before 1992” (in reality it shipped in mid-1993), and at the end of 1991, Microsoft simply did not have anything beyond demos for 32-bit Windows application writers. However, others did.
Watcom C/386 8.5
In August 1991, Watcom Systems of Ontario, Canada shipped version 8.5 of the Watcom C/386 32-bit compiler, with a $795 introductory price. This was a watershed product for two reasons.
Watcom C/386 8.5 was the first compiler to ship with a royalty-free DOS extender (Rational’s DOS/4GW 1.0). Until then, extended DOS application developers had to purchase a 32-bit compiler in the $1,000 price range as well as a DOS extender (from companies such as PharLap or Ergo) which would cost around $500. DOS extenders also typically required developers to pay royalties, which made 32-bit DOS development quite expensive.
The other reason why Watcom C/386 8.5 was significant was because it included support for 32-bit Windows application and DLL development. Rather than waiting for Microsoft to design and implement a 32-bit Windows API, Watcom applied the proven DOS extender idea to Windows. This was made easier by the fact that Windows 3.0 in fact included a rudimentary 32-bit memory management interface.
Watcom’s Windows extender was called Win386—not to be confused with Windows/386, sometimes shortened to Win/386; those referred to the original Windows/386 product and later to the Enhanced mode component of Windows 3.x. The work on Win386 started in November 1990; Win386 was initially developed by Craig Eisler. In 1993, Craig Eisler left Watcom and went to work for Microsoft, where he worked on WinG and became one of the main DirectX developers. Win386 was then further developed by Fred W. Crigger at Watcom (and Powersoft/Sybase).
The Win386 extender remained part of the source code opened up by Sybase in 2000, which formed the basis of the Open Watcom tool set. Win386 is still available as part of the latest Open Watcom release (version 1.9 as of this writing).
The way Win386 worked was fundamentally no different from extended DOS applications. The core application logic was 32-bit, but all interfaces to the (16-bit) operating system went through translation wrappers. On Windows, the situation was slightly more complicated than on DOS because not only was the application calling Windows, but Windows was also frequently calling the application. So-called callback functions were critical to Windows application design and included the window procedure, the heart of any Windows application.
Watcom provided specially adapted Windows API header files (
windows.h etc.) as well as 32-bit Windows libraries. Modifying cleanly written 16-bit Windows code was relatively easy and with a bit of care, it was possible to write code which could be compiled as either 16-bit or 32-bit.
At the core of Watcom’s Win386 was the “supervisor”, or extender; it was a relatively small library (less than 40KB) containing both 16-bit and 32-bit code and linked with the user’s 32-bit Windows executable.
The supervisor contained a standard 16-bit NE format module which interfaced with the Windows environment. Additionally, the supervisor implemented a 32-bit memory allocator based on DPMI and capable of managing a flat address space. A large chunk of the supervisor consisted of “covers” (thunks) for Windows APIs. The covers managed translation between the 32-bit and 16-bit environments.
The Win386 supervisor also included a small DOS extender because many Windows 3.x applications needed to use the DOS INT 21h interface for functionality not provided by Windows.
The actual 32-bit application was linked as a PharLap format executable (typically with a .rex file extension). The 32-bit executable was then processed with the
wbind utility which bound it with the supervisor and added Windows resources if needed.
One of the advantages of Watcom Win386 was that it was extremely easy to deploy and highly compatible with various Windows environments. Because the supervisor was bound with the 32-bit executable, a Win386 application did not require any DLLs or VxDs to be installed on the system and could be launched directly. Win386 applications also ran on Windows NT, Windows 9x, and Win-OS/2, in addition to plain Windows 3.x in Enhanced mode.
Watcom’s Win386 was not the only game in town. There were at least three competing products: BigWin from Rational Systems, the 32-bit Windows ADK (Application Development Kit) from MetaWare, and MicroWay’s NDPWIN, all released in 1991. BigWin was significantly more expensive ($5,000, not including a 32-bit compiler) than Watcom’s solution and required royalty payments for shipping applications. MetaWare’s ADK was only slightly higher priced than Win386; the ADK itself cost $495 and about $1,095 when bundled with the MetaWare 32-bit compiler. Like Watcom, MetaWare did not require royalties. MicroWay’s NDPWIN SDK was listed at $1,495 and required a $895 NDP compiler (a choice of C/C++/FORTRAN/Pascal).
Rational’s BigWin product did not find any customers. It’s unclear if MetaWare’s and MicroWay’s products fared any better. However, it is known that Watcom’s Win386 found use in several high-profile products.
Determining which products used Win386 is tricky. With the executables at hand, it’s easy to see whether Win386 is included or not, but getting access to Windows applications from the 1992-1994 era is far from simple. One of the best sources of information turned out to be searching for certain error messages produced by Win386 in some situations.
Probably the most widespread product built on Watcom’s Win386 was FoxPro 2.6 for Windows, a relational database developed by Fox Software and later bought by Microsoft. Both the DOS and Windows versions of FoxPro 2.5 and 2.6 were built with Watcom’s compilers as 32-bit applications.
Probably for technical reasons, Microsoft’s purchase of Fox Software did not change the situation and FoxPro 2.5, published by Microsoft in 1993, was still built with Watcom’s compiler and the Windows version was based on Win386. The later FoxPro 2.6 and 2.6a likewise utilized Win386. The Win386 extender was used not only by FoxPro itself but also by redistributable executables based on the FoxPro run-time.
Another well known application which used Win386 was Autodesk’s AutoCAD R12 for Windows and the first release of AutoCAD LT (1993).
Not surprisingly, Watcom’s own SQL database (Watcom SQL or WSQL) also used Win386. So did the Windows based components of Novell’s Btrieve 6.x. It’s obvious that database managers were especially limited by the 16-bit Windows 3.x architecture and benefited from 32-bit extenders.
Watcom C/386 was used for the development of numerous 32-bit DOS games, and in some cases also for Windows games. Some of Sierra On-Line’s famous titles supported both DOS and Windows, with the Windows versions using Win386. Sierra’s SCI2 engine (also known as SCI32) used DOS/4GW for the DOS-based versions and Win386 for the Windows-based executables. The games were typically shipped on CD-ROM and both DOS and Windows versions used the same data files.
The Sierra games which shipped with Win386-based executables include Gabriel Knight: Sins of the Fathers (1993), Quest for Glory IV: Shadows of Darkness (1993/1994), King’s Quest VII: The Princeless Bride (1994), and The Beast Within: A Gabriel Knight Mystery (1995), one of Sierra’s most lavish productions. Note that this is not an exhaustive list of Sierra’s games which utilized Win386.
Old Win386 on new processors
The versions of Win386 shipped with Watcom C/386 version 8.5 and 9.0 included a timing loop which failed on CPUs faster than about 300 MHz, some 6-7 years after the initial Win386 release. The Win386 versions in Watcom C/386 9.5 (released Jan 1994) and later no longer contain the timing loop; it’s unclear what its purpose was.
One of the applications affected by the problem was FoxPro for Windows 2.5 and 2.6. In the late 1990s, a patch was developed for the issue. This patch is available from Microsoft under KB240982. There are actually two patches, one specifically for the US version of FoxPro 2.6a and another for international versions of FoxPro. The “international” patch, IPatchFP.exe, is in fact a completely generic patch which works for any Win386 application. It was successfully used to patch sample 32-bit Windows applications built with Watcom C/386 8.5 and 9.0.
Around 1995, Win32 finally became mainstream (only a few years late), especially in its Win32s and Win32c incarnations. Using Windows extenders was no longer an attractive option in most cases; it made more sense to develop Win32 applications which could run on Windows NT and Windows 95 directly, and on Windows 3.x with the Win32s add-on.
Win386 did not stop working, but no longer provided any significant advantage and no new major applications used it since approximately 1995. But Win386 had done its job and enabled mainstream 32-bit Windows applications years before Microsoft provided the functionality.
Update: Before Microsoft had any actual 32-bit Windows development tools, they may have mentioned Watcom’s Win386 to customers as a way to bolster the Windows story. Watcom’s 32-bit Windows development tools are mentioned in a Feb 1991 internal Microsoft memo, written by Brad Silverberg (bradsi) and mentioning the “just announced” Watcom 32-bit Windows development support.
Of course, these extenders has problems like no memory protection (some of which still existed in Win9x!) which 32-bit OS/2 didn’t have, which Paul Maritz of MS seems to have completely ignored back in 1990 (as evident by PX00307).
I just find it a shame that Win64 can’t (or didn’t) properly handle Win16 apps. I know there is some very limited hardware (16-bit pmode) support, but apparently MS didn’t find it worth emulating (and maybe would’ve also had to emulate DOS, DPMI, etc., which I guess is a lot of work). I’m no huge fan of Win16 and have no favorites from that era (I generally prefer DOS), but it’s a shame that so many apps are literally abandoned. Esp. when something is totally 32-bit but uses 16-bit installer, doh!
Though I will say that the KQ6 CD came on my 486 Sx/25 w/ 4 MB and is one of the more impressive memories I have. The fact that their budget was $1 million was impressive, to say the least. Whereas nowadays you need at least 2 GB RAM for a single game (blech).
I still have GK1 and QFG4 CDs, so I should take a closer look at those one of these days (though already beaten latter in at least one character). I wonder if Win386 works in WINE.
Well, AMD didn’t think that anyone needed to mix 16-bit and 64-bit code. There’s no segmentation and no V86 mode in long mode, which makes implementing NTVDM really difficult. Yes, to get Win16 support they would have to emulate the whole lot, DOS and DPMI and whatnot.
The truth is that Microsoft simply doesn’t want to spend time on it anymore, and who could blame them. If you want to run some 16-bit dinosaurs, use virtualization. Microsoft simply can’t justify spending money on it because honestly, how many people are going to pay extra for 16-bit support?
Virtualization doesn’t offer seamlessy integration with the host OS, and you’re forced to buy a license of MSDOS-Win3.1 for each station that you want to virtualize (abandonware legal status and validity is questionable on many countries, US included).
On any case, isn’t need a V86 mode support isn’t need to make NTVDM work on NT, as Windows NT RISC versions showed at time. If they would wanted to add NTVDM support to x64 windows versions, they just could follow the paths and tricks that they used to support DOS and windows on RISC processors, and add a full VCPU emulation. Even they could improve the old tech that they used on those older versions of windows with the VCPU tech that they adquired from Connectix, in place of the very poor effort that they did with the bogus Windows VPC addon that is only available on Ultimate version of Windows.
Is better say that they didn’t because they wanted to bury his past mistakes on x64 and future platforms. That’s all.
Greetings. And good article about DOS 4 :-).
The fact that virtualization doesn’t offer “seamless integration” with the host (whatever it means exactly) is also its strength. Many users are quite keen on keeping things isolated for security and other reasons.
And I really don’t think Microsoft wanted to bury their past mistakes. If they wanted to do that, there would never be DOS 2.0 or Windows 2.0 🙂 I’m sure they simply did the math and determined that it’s not worth the effort for them. Having 90+% of the market and no serious competition helps too – there is no OS/2 (or whatever) that would offer such feature, so it’s not like Microsoft is going to lose any customers by dropping NTVDM from the 64-bit versions.
I would not call IPatchFP.exe a completely generic patch, because the included patch2x.exe needs Windows 9x or NT for execution. If I remember correctly the first one was dzpatch.exe with same limitation. Everything can be found still
here. The MS download links seem no longer to work. Perhaps somebody knows about a patch that’s also working on DOS or OS/2 systems.
Michal, it is amazing what one can find in your post. This is one of very few articles on the web that actually mention BigWin – I guess one of biggest failure of Rational. The so called Windows Extender era wasn’t designed to be alive for long – quite oposit to the DOS Extenders saga.
It would be quite interesting to hear a story of the developers of those products and learn the number of licences they’ve actually sold back then.
Correction: V86 mode don’t work in long mode. Segmentation still work for 16-bit and 32-bit code even in long mode.
Pingback: Useful Info On Win16-Targeting Compilers… And a List of DOS/Win16 Resources | Stephan Sokolow's Blog
I know this is a decade late, but I just discovered this post. BigWin *did* have at least one customer – the company I was working for at the time. We were migrating a large 32-bit Unix application to Windows 3.1, and despite our best efforts we couldn’t shoehorn it into 16 bits. This was in 1991-1992, before Win32s was available. At the time BigWin seemed a marvel – 30 years later, I still remember the thrill of being freed from 64K segments.
Despite some troublesome bugs it worked well enough that we did 3 or 4 releases with it in 1993 and 1994. I think we used it with the 32-bit MetaWare High-C compiler. Rational stopped supporting it around 1994, but they gave us the source code as a parting gift. We switched to Win32s (and ultimately Windows 95 and NT) after that.
Cool! I wonder if you were the only customer, or one of very very few.
I don’t suppose any of the BigWin source code survived? 🙂