The 32-bit Revolution—the first 32-bit version of OS/2
When IBM officially released OS/2 version 2.0 on March 31, 1992, it was not entirely unexpected. In fact, 32-bit OS/2 had been promised since the very beginning of the OS/2 era and in his Inside OS/2 (published in 1988), Gordon Letwin clearly outlined the features of “OS/2 – 386”. The development of 32-bit OS/2—codename Cruiser—started probably sometime in late 1988 when IBM and Microsoft were beginning to work on OS/2 1.2, and also roughly at the same time when Microsoft initiated the development of NT, first known as OS/2 NT and eventually released as Windows NT. When IBM (alone) was later working on OS/2 1.3, the development of Cruiser was already well underway. The lead architect of OS/2 2.0 was Michael S. Kogan, co-author of the excellent The Design of OS/2 textbook.
OS/2 2.0 could have looked like this:
The above screenshot was taken from the Comdex Fall ’91 pre-release of OS/2 2.0 (build 6.167). In December 1991, IBM followed it with a slightly improved “Limited Availability” release of OS/2 2.0 (build 6.177). That release was, as the name implies, not sold in retail and was only supplied to beta testers and “special” customers. OS/2 2.0 LA was shipped sometime in December 1991—perhaps to annoy Microsoft’s Steve Ballmer who publicly announced that he would eat a floppy disk if IBM managed to release OS/2 2.0 by the end of 1991. Another possible reason for the LA release was the fact that IBM promised its customers to deliver a 32-bit OS/2 in 1991, and IBM usually keeps its promises, one way or another.
The Comdex ’91 pre-release looked very much like the GA (General Availability) release but it was clearly unfinished and came with a long README file detailing all the little things that didn’t work yet. The major missing feature was seamless Win-OS/2, ie. the ability to run Windows 3.0 applications on the OS/2 Desktop. The OS/2 2.0 pre-release did support Windows applications, but only in a fullscreen session. It is interesting to note that in the 6.167 pre-release the built-in version of Windows wasn’t labeled “IBM Win-OS/2”, it was simply “Microsoft Windows 3.0a”, and as far as can be ascertained most of the binaries were in fact identical to Windows 3.0a.
The Comdex ’91 OS/2 2.0 pre-release also had a slightly different look—as the above screenshot shows, the windows mini-icons were separate on the title bar instead of replacing the system menu button. This is reminiscent of the old IBM CUA ’91 demo, just like the “Contents”label on the open folder.
The released OS/2 2.0 GA looked like this:
The difference wasn’t big, although the GA desktop was a bit more densely populated.
The Big Thing
The biggest thing in OS/2 2.0 was the operating system itself. But perhaps the single most important and new feature was the user interface, also known as the Workplace Shell (WPS for short). It was a radical departure from the GUI of OS/2 1.3 or Windows 3.0. The new interface was object oriented and everything was now an object: a drive object, a printer object, a program object, a shredder object, etc. The objects could be manipulated through drag and drop—moved, copied, printed, shredded, and so on. The WPS made the second mouse button finally useful and used it to open pop up menus as well as perform drag and drop (but everything was of course configurable).
It should not surprise anyone that some OS/2 2.0 beta testers strongly objected against the WPS. Few years later many people (possibly even the same people) claimed that the WPS was the feature of OS/2. There was some truth to both viewpoints: The WPS was a very innovative and powerful desktop metaphor, but especially the initial implementation was rather rough around the edges and significantly increased the memory requirements for OS/2 2.0. Some OS/2 users claimed that releasing the WPS in OS/2 2.0 was a mistake, and first a 32-bit OS/2 with classic Presentation Manager should have been released, followed by a new user interface later, when both the base OS and SOM/WPS would be more solid. Who was right will never be known.
The Technology
OS/2 2.0 was the first widely used 32-bit operating system for PCs. It offered programmers a fully 32-bit API and a flat programming model which did away with the dreaded segments and 64K object size limits. The first 386 DOS extenders such as PharLap 386|DOS had appeared in the late 1980s, but they tended to have all kinds of issues of their own and programming in DOS extended environments was anything but straightforward.
Internally, the 32-bit story was a bit different. Very large parts of the system were still 16-bit—the major reasons were time constraints and compatibility. Time constraints caused the Graphics Engine (and hence Presentation Manager drivers for video and printers as well) to be still 16-bit in OS/2 2.0. The Graphics Engine was later replaced with a 32-bit version in OS/2 2.1. Compatibility dictated that OS/2 2.0 used 16-bit Physical Device Drivers (PDDs) initially written for OS/2 1.3. Large parts of the OS/2 kernel were also 16-bit to support old 16-bit OS/2 applications, including applications which directly accessed some OS internals. The file systems and the entire storage subsystem were 16-bit (though structured somewhat differently than OS/2 1.3), just like all networking code (available separately and not part of the base OS/2 2.0 product).
But major parts of the system were completely new and fully 32-bit, such as the Multiple Virtual DOS Machine (MVDM) support or the memory manager with support for paging. For the most part the new code was written in C, unlike the old assembly code from OS/2 1.x.
The Integrating Platform
The Integrating Platform was IBM’s trademark for OS/2 2.0. It referred to the unique capability to run existing DOS, Windows, and OS/2 1.x applications in addition to new 32-bit OS/2 software. Unlike OS/2 1.x, version 2.0 had excellent DOS support. It took full advantage of the Virtual 8086 mode of the Intel 386 and later CPUs. And not only it allowed multiple windowed or fullscreen session running all at the same time but it also let users create “specific”DOS sessions which weren’t using the built-in DOS support, and could boot DOS 4.0, 5.0, DR-DOS, or even something like CP/M.
The Windows application support was a logical extension of DOS support. Full-screen Win-OS/2 sessions would run essentially unchanged Windows 3.0 inside a virtual DOS machine. Seamless Win-OS/2 sessions were a lot trickier because they had to coordinate with Presentation Manager applications. That was achieved through special versions of Win-OS/2 display drivers. The approach IBM took possibly provided maximum performance but unfortunately had one major drawback—it made creating OS/2 display drivers even harder (in other words more expensive) and undoubtedly was one factor contributing to the limited availability of drivers later on. Vendors had to create a full-fledged OS/2 driver as well as an OS/2 specific version of a Windows driver. What IBM could have done instead was to create a “bridge”driver mapping Win-OS/2 to PM calls and only require vendors to supply an OS/2 driver (that was exactly the approach taken later with the GRADD drivers).
The DOS support in OS/2 was excellent. Many users ran OS/2 even though they used primarily DOS applications, simply because of the added multitasking capabilities. OS/2’s DOS support was much better than the DOS boxes in Windows NT (NTVDM) and probably also better than the DOS support in Windows 9x (which appeared more than three years later).
In retrospect, the very good level of DOS and Windows application support was a double-edged sword. While it attracted more users by preserving their investment in DOS and Windows software, at the same time it also discouraged developers from writing native OS/2 programs. By developing for DOS/Windows, they could target the DOS/Windows and OS/2 markets. The net effect was certainly positive in the short term, but quite possibly self-defeating in the long term.
Installation
IBM was selling OS/2 2.0 versions on 3½” and 5¼” HD floppies; there was no CD-ROM installation support (later in 1992,OS/2 2.00.1 could be installed from CD-ROM, but the CDs wereonly available to developers,and OS/2 2.0 only supported a few SCSI CD-ROMs). The tested version was delivered on 3½” floppies, 21 disks total.
The test system was a Pentium III running at 600 MHz with 256MB RAM installed. The installation wasn’t entirely smooth—the first obstacle was that one of the 21 floppies had developed bad sectors over the years (not entirely surprising). Of course the bad floppy was the most important one, the Installation diskette. Luckily a generous old-time OS/2 user soon provided a good floppy image. The next problem was that OS/2 started rebooting the test machine when loading from the floppies. After tweaking the machine’s BIOS settings a little and disabling the CPU caches, everything started working—the problem turned out to be a “known issue” on fast machineseven with OS/2 2.1. After that the installation was quite uneventful.
On the test machine the ancient version OS/2 ran blazingly fast—booting up from Boot Manager to fully populated Desktop only took about 9 seconds. Too bad modern operating systems aren’t that fast.
The list of supported hardware in OS/2 2.0 was quite short. Essentially IBM hardware was supported, but the number of drivers for non-IBM devices was very short. This is perhaps not surprising given that in the OS/2 1.x era, the IBM OS/2 releases were only meant to support IBM’s own hardware and Microsoft handled all other OEMs. The driver situation was much improved (but by no means fully resolved) by the time OS/2 2.1 was released.
Applications
OS/2 2.0 faced the same problem as OS/2 1.x several years earlier:Lack of applications. It could run most existing DOS, Windows, and OS/2 1.x applications, but it would take a while for the new 32-bit apps to appear. IBM was naturally the first to deliver 32-bit software such as DB2/2, CSet/2 or LAN Server.
Several OS/2 applications from the 1992-1993 period were installed on the test system. The first of them is CorelDraw 2.5:
Before that, Corel reportedly released a 16-bit OS/2 version of CorelDraw 2.0 for OS/2 1.3. Version 2.5 was a complete suite of programs like Draw, Chart or PhotoPaint:
Unfortunately the package looked like a very quick and dirty porting job because apart from Draw and Mosaic, all the other programs were Windows 3.x versions. CorelDraw didn’t even have native OS/2 help, just a big Windows help file.
But apart from that, CorelDraw was a capable vector drawing program. It could export the images in EPS format, which made it easy to include them in various desktop publishing applications (including TeX).
CorelDraw even had competition—Micrografx Designer, developed by Micrografx and (just like CorelDraw) avaliable in a Windows version as well.
At a glance, Designer seemed more complete and polished than Corel Draw. It did not come with an equivalents of tools like PhotoPaint, but it was supplied with an extensive library of clipart and fonts. Another difference between those programs was that in CorelDraw, the preview window was separate and not editable. In Designer it was possible to turn on preview mode and directly edit the drawing, or the user could edit just the wireframe representation.
Micrografx Designer was developed using Micrografx’s own Mirrors software:
Interestingly enough, it appears that CorelDraw used Micrografx Mirrors as well.
Micrografx originally developed Mirrors for OS/2 1.x and closely collaborated with IBM on developing a 32-bit version. Mirrors was conceptually identical to IBM’s later Open32 in that it enabled source portability between Windows and OS/2 (but unlike Open32, which aimed for Win32 compatibility, it was targeting 16-bit Windows). It may be interesting to note that Messrs. Delimon and English were co-authors of the well-known programming book Real-World Programming for OS/2 2.11.
Compilers
As with OS/2 1.x, OS/2 2.0 was a good development platform. Even if it was not as stable as a 32-bit protected mode OS can be, it was a far cry from the near-unbroken sequence of crashes, lockups and reboots so familiar to DOS and Windows 3.x developers. Within a year of the OS/2 2.0 release, several 32-bit compilers were released. All major compiler vendors supported 32-bit OS/2—with the notable exception of Microsoft of course.
OS/2 1.x was developed exclusively using Microsoft tools. Initial phases of OS/2 2.0 development relied on Microsoft compilers as well, namely the compiler designated as “Microsoft C 386 Compiler”, never marketed as a retail product and still available on the OS/2 DDK and used for building certain device drivers (as well as parts of the OS/2 kernel). The MS C 386 compiler dated back to 1989.
After the rift in 1990, it was clear to IBM that they could no longer rely on Microsoft to supply OS/2 compilers. Not least because even in 1992, Microsoft didn’t yet have a retail 32-bit compiler available, which would have made it quite difficult for ISVs to obtain OS/2 2.0 development tools. Therefore the IBM Toronto lab developed a 32-bit OS/2 C compiler known as CSet/2. There wasn’t much to see in CSet/2 and on the test machine was installed its successor released in early 1993, IBM CSet++.
IBM has a knack for confusing its customers with its byzantine product naming and complicated product relationships. CSet++ was no exception and actually consisted of three more or less stand-alone packages:
- C/C++ Tools—the actual C/C++ compiler, class libraries, debugger, browser and profiler.
- WorkFrame/2—an object-oriented integrated development environment.
- OS/2 Toolkit—a collection of headers, libraries and tools for OS/2 development.
The relationship between these packages was quite intricate: C/C++ Tools required the Toolkit to link even the simplest program and could use, but did not require, the WorkFrame. WorkFrame was useless by itself but could theoretically support any OS/2 compiler (any vendor, any programming language). Ditto for the Toolkit.
C/C++ Tools 2.0 (the first version of the IBM compiler with C++ support) could use Workframe 1.1 and OS/2 Toolkit for OS/2 2.0 or 2.1. As is obvious from the following screenshot, C/C++ tools came with a debugger, profiler (also known as Execution Analyzer) and a C++ class browser, as well as an extensive C++ class library and online documentation.
Perhaps the most powerful tool in the package was IBM’s debugger, IPMD:
IPMD was an excellent OS/2 debugger, on par with the best on any platform.As mentioned earlier, C/C++ Tools used the IBM WorkFrame/2 as its IDE:
WorkFrame/2 1.1 itself was very small – it was just a framework. It would launch external editors, make programs, compilers, debuggers, and so on.
The next compiler was Borland C/C++ version 1.0 for OS/2, released at approximately the same time as IBM’s CSet++ 2.0 (first half of 1993):
Borland C++ sported the famous IDE, very similar to the Windows version of Borland’s compilers, with syntax highlighting, integrated debugging and other goodies:
Borland also had a standalone version of Turbo Debugger:
Turbo Debugger GX was not as powerful as IPMD but it was quite usable. But Borland had one tool that no other OS/2 compiler did—the Resource Workshop:
Many programmers felt that the Resource Workshop was superior to the tools offered as part of the OS/2 Toolkit. That is perhaps not very surprising—one look at Borland’s tools was enough to determine that Borland was much more concerned with the visual appearance of their tools than IBM ever was.
Least concerned about its looks was yet another compiler, Watcom C/386 9.0. Comparing it against Borland C++ 1.0 is probably unfair because Watcom C/386 9.0 predates it by about a year. Watcom was one of the first companies to offer a 32-bit OS/2 compiler—it had supported 16-bit OS/2 development earlier and started work on 32-bit OS/2 support in 1991.
Watcom C/386 9.0 was different from the other two compilers: It only supported C development, it didn’t have absolutely any GUI tools, it didn’t create any folders or icons on the Desktop. The only tool that wasn’t command-line only was the debugger, WVIDEO:
But Watcom had something the other compilers didn’t: It was a cross-compiler. It could build 32-bit OS/2, DOS, and Windows programs (Watcom supported 32-bit development on Windows 3.x through proprietary extender technology long before Win32s appeared), in addition to Netware and AutoCAD ADS development. It came with the well-known DOS/4GW extender (version 1.8). Watcom 9.x was used for the development of highly successful games such as DOOM.
In 1993, Watcom released version 9.5 of the compiler, which added support for C++ as well as building of Windows NT targets. With the exception of C++ support, the OS/2 portion of 9.5 was not appreciably different from 9.0—still no GUI tools. That had to wait until version 10.0, released in 1994.
The overview of the OS/2 development tools cannot be complete without mentioning EMX GCC. EMX stands for Eberhard Mattes eXtender. Eberhard Mattes was an enterprising German programmer who created the EMX package to simplify porting of Unix software to OS/2 2.0 and DOS. Programs created with EMX (and some foresight) could run on OS/2 as well as DOS because EMX.EXE was a 386 DPMI-compatible DOS extender. Eberhard Mattes himself used EMX to create emTeX, the DOS and OS/2 version of the TeX typesetting package.
For comparison purposes, an old version (0.8d) of EMX GCC from May 1992 was installed on the test system. Compared to compilers from IBM, Borland or Watcom, EMX was almost totally unsuitable for creating OS/2 (especially Presentation Manager) programs, although it was a much better choice for porting Unix programs. The early version of EMX had no support for OMF object files, hence libraries written for the other compilers couldn’t be used. EMX could not create DLLs and on the whole it felt very “foreign”. It was free but poor documentation and lack of OS/2 specific features made it a bad choice for writing OS/2 programs from scratch. Unlike the other compilers, EMX did not come with the OS/2 Toolkit, which was a major shortcoming. But the ease of porting Unix programs with EMX was the reason why almost every OS/2 user had EMX.DLL on his or her machine.
The release of OS/2 2.0 was undoubtedly an important event in the PC history. The first 32-bit release felt somewhat bare in comparison to the later versions—it had no built-in networking or multimedia support for instance. But it was a solid base for a new breed of 32-bit applications, and it was a “better DOS than DOS”.
OS/2 2.0 didn’t take over the world—perhaps unfortunately. But it certainly showed what a 386-based PC could do with an operating system not designed for a machine two or three generations older.
Acknowledgements
Thanks to John Martin Alfredsson for the OS/2 2.0 pre-release floppies and more. Thanks to Will Honea for coming to the rescue when a bad floppy jeopardized OS/2 2.0 installation.
The Design of OS/2 by H.M. Deitel and M.S. Kogan, published by Addison-Wesley in 1992, provides a few interesting facts that are difficult to find anywhere else.
