OS/2 2.0

When IBM released OS/2 version 2.0 in March 1992, it was not entirely unexpected. In fact, 32-bit OS/2 had been promised since the very beginning of OS/2 and in his Inside OS/2 (remember that this book was published in 1988), Gordon Letwin clearly outlined the features of "OS/2 - 386". The work on 32-bit OS/2 - codename Cruiser - started probably sometime in l988 when IBM and Microsoft were on another front busily hacking at OS/2 1.2. When IBM (alone) was 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 excelent (albeit rather technical) book The Design of OS/2.

This time we'll jump directly to some screenshots. OS/2 2.0 looked like this:

Now I hear the OS/2 old timers shouting, "It didn't!" - but rest assured that this is no error on my part. The above screenshot was taken on OS/2 2.0 LA - that's "Limited Availability" (now a collector's item I suppose). This 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 November 1991 - probably 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 (Mr. Ballmer unfortunately did not eat the floppy publicily and certain evil minded people immediately suggested that he did not keep his word. Some people will just stop at nothing to tarnish the shining image of Microsoft). Another possible reason for the LA release was the fact that IBM promised its customers to deliver 32-bit OS/2 in 1991 and IBM usually keeps its promises, or at least tries to.

The LA version looked very much like the GA (General Availability) release but it was visibly 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. ability to run Windows 3.0 applications on the OS/2 Desktop. OS/2 2.0 LA however did support Windows applications, but only in a fullscreen session. It is interesting to note that in 2.0 LA the built-in version of Windows wasn't labeled "IBM Win-OS/2", it was simply "Microsoft Windows 3.0a" and as far as I can tell most of the binaries were in fact identical to Windows 3.0a.

OS/2 2.0 LA also had slightly different look - as the 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.

OK, now let's take a look at the "real thing". OS/2 2.0 GA looked like this:

As you can see, 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 whole system itself. But perhaps the single most important and new feature was the user interface, a.k.a. 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: drive object, printer object, program object, shredder object and so on. 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 naturally configurable).

It should not surprise anyone that some OS/2 2.0 beta testers strongly objected against the WPS. Few years later many people (probably the same people) claimed that WPS was the feature of OS/2.
 

The technology

OS/2 2.0 was the first widely used 32-bit operating system for PCs. It offered programmers fully 32-bit API and flat programming model which does away with the hated segments as well as 64K limitations. I still remember when I switched from 16-bit to 32-bit programming (that was under DOS though) and felt so relieved. First 386 DOS extenders like PharLap appeared in late 1980's but they always had all kinds of "issues" and programming for them wasn't always easy (bimodal interrupt handlers anyone?).

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 that the Graphics Engine (and hence Presentation Manager drivers for video and printers as well) was still 16 bit in OS/2 2.0 but later replaced with 32-bit version in OS/2 2.1. Compatibility dictated that OS/2 2.0 used 16-bit Physical Device Drivers (PDDs) compatible with OS/2 1.3. Similarly large parts of the OS/2 kernel were 16-bit to support old 16-bit OS/2 applications.

But major parts of the system were completely new and fully 32-bit, such as the Multiple Virtual DOS Machine (MVDM) support or memory manager with support for paging. For the most part the new code was written in C, unlike the old assembly code in 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 PM/WPS apps. This 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 harder (in other words more expensive) and undoubtedly was one factor contributing to the limited availability of drivers later on. This way, 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 is create a "bridge" driver mapping Win-OS/2 to PM calls and only require vendors to supply an OS/2 driver (this is the approach taken by the newer GRADD drivers).

But 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. I personally believe OS/2's DOS support to be second only to real DOS and better than Windows 9x (not to mention NT).

With the benefit of hindsight I can safely say that 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 discouraged developers from writing native OS/2 programs because by developing for DOS/Windows they could target the DOS/Windows and OS/2 markets. I believe the net effect was still positive but probably not nearly as much as IBM initially expected.
 

Installation

I have recently managed to buy a copy of OS/2 2.0, still shrink-wrapped. IBM was selling versions on 3.5" and 5.25" HD floppies as well as CD-ROM versions, although CD-ROM drives were far from common in 1992 and OS/2 2.0 only supported few SCSI CD-ROMs. My version is on 3.5" floppies, 21 disks total.

I installed OS/2 2.0 on my home machine, a PIII-600 with 256MB RAM. The installation wasn't entirely smooth - the first obstacle was that one of the 21 floppies had developed bad sectors over the years - not too surprising. And I likewise didn't find it surprising that the bad floppy was the most important one, the Installation diskette. But I managed to obtain a floppy image soon thanks to a generous old-time OS/2 user. Then OS/2 started rebooting my machine when booting from the floppies. So I played with my machine's BIOS settings a bit, disabled CPU caches and everything started working - later I found out that this was a "known issue" even with OS/2 2.1. After that the installation was quite uneventful.

On my machine this ancient version OS/2 runs blazingly fast - booting up from Boot Manager to fully populated Desktop only takes about 9 seconds. Too bad eComStation isn't that fast.
 

Applications

OS/2 2.0 faced the same problem as OS/2 1.x few years before - 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 first to deliver 32-bit software such as DB2, CSet/2 or LAN Server.

I have sampled few applications from the 1992-1993 with special emphasis on compilers (application development is my job you know). The first of them is CorelDraw 2.5:

Before that, Corel apparently had 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 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 fairly capable vector drawing program. I'm no graphics artist but I have several times successfully used CorelDraw to create figures in EPS format for inclusion in TeX documents.

And CorelDraw even had competition - Micrografx Designer, developed by Micrografx and just like CorelDraw avaliable in a Windows version as well.

I haven't extensively used either of these apps but Designer seemed more complete and polished to me. It did not come with 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 one 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 Open32 in that it enabled source portability between Windows and OS/2 (but unlike Open32 it was targeting 16-bit Windows). It is 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.

I unfortunately haven't managed to get my hands on any OS/2 wordprocessor from the 1992-1993 era - maybe one day I will.

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 constant stream 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. I think it is safe to say that 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 (and perhaps even parts of the OS/2 kernel). I have MS OS/2 2.0 SDK from mid-1990 which includes this compiler and C runtime libraries. By the way, the LINK386 in that SDK produced LE executables, not LX.

But after the rift in 1990, it was clear to IBM that they could no longer rely on Microsoft to supply OS/2 compilers. For one thing, in 1992 Microsoft didn't even have a retail 32-bit compiler available. Hence the IBM Toronto lab developed a 32-bit OS/2 C compiler known as CSet/2. I unfortunately do not have CSet/2 but I have its successor (actually I have most of its successors) released in early 1993, IBM CSet++.

IBM is usually pretty good at confusing its customers with its product naming and complicated product relationships. CSet++ was no exception and actually consisted of three more or less stand-alone packages:

The relationship between these packages was quite intricate:  C/Ct++ 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. Ditto for Toolkit.

C/C++ Tools 2.0 (the first version of the IBM compiler with C++ support as far as I know) 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/Ct++ tools came with a debugger, profiler (aka 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 always was and still is the best OS/2 debugger and probably near the top for any platform.

As I 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 in line is Borland C/C++ for OS/2 version 1.0, released at approximately the same time as C/C++ Tools 2.0 (i.e. 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 usable. But Borland had another thing that no other OS/2 compiler had - the Resource Workshop:

Many programmers felt that Resource Workshop was superior to the tools offered as part of the OS/2 Toolkit. That is perhaps not very surprising - one look at Borlands tools is enough to determine that Borland was much more concerned with the look of their tools than IBM.

Least concerned with the looks was the third compiler I looked at, Watcom C/386 9.0. Comparing it against C/C++ Tools 2.0 and Borland C/C++ 1.0 is probably unfair because Watcom C/386 9.0 predates them 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 (according to the OpenWatcom source code).

Watcom C/386 9.0 was very different from the other two compilers - for one thing, 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 supported building of 32-bit OS/2, DOS and Windows programs (Watcom supported 32-bit development on Windows 3.x long before Win32s through proprietary extender technology), in addition to Netware and AutoCAD ADS development. It came with the well-known DOS/4GW extender (version 1.8). It is perhaps useful to note that Watcom 9.x was used for development of such smash hits 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 or anything. That had to wait until version 10.0, released in 1994. But that's perhaps a topic for some other time.

The overview of the OS/2 development tools cannot be complete without mentioning emx gcc. I believe emx stands for Eberhard Mattes eXtender. Eberhard Mattes is an enterprising German programmer who created the emx package to simplify porting Unix software to OS/2 2.0 and DOS. Programs created with emx (and some foresight) can run on OS/2 as well as DOS because EMX.EXE is a 386 DPMI-compatible DOS extender. Eberhard Mattes himself used emx to create emTeX, the DOS and OS/2 version of the excellent typesetting package TeX.

After some poking around I have found an ancient version (0.8d) of emx gcc from May 1992. Compared to compilers from IBM, Borland or Watcom, emx was almost totally unsuitable for creating OS/2 (especialy PM) 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 it couldn't use libraries written for the other compilers. It 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 poor 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 is the reason why almost every OS/2 user has EMX.DLL on his or her machine.

But back from compilers to OS/2. The release of OS/2 2.0 was undoubtedly an important point 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 - 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 very rare OS/2 2.0 LA and more. I feel that a look at OS/2 2.0 LA made this article much more complete. Thanks to Will Honea for coming to the rescue when I was bitten by a bad floppy.

The Design of OS/2 by H.M. Deitel and M.S. Kogan, published by Addison-Wesley in 1992, provided me with some interesting facts that are very difficult to find anywhere else. It is a very in-depth book that every OS/2 programmer should read.