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.
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
people) claimed that WPS was the feature of OS/2.
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 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.
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.
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.
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:
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.
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.