Watcom Win386

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).

Win386 Implementation

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.

Competing Products

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.

Win386-based Applications

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.

Win32 Arrives

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.