VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]
|
VOICE Home Page: http://www.os2voice.org |
November 2001
[Newsletter Index]
|
| By Michal Necasek © November 2001 |
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 a 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. A few years later many people (probably the same 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 the Graphics Engine (and hence Presentation Manager drivers for
video and printers as well) to be 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 use 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 a few applications from 1992 and 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; while 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. I suspect that even
initial phases of OS/2 2.0 development relied on Microsoft compilers - the compiler
designated as "Microsoft C 6.0 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).
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.
[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org