OS/2 1.0

The evolution of OS/2 started - well, a long time ago. Probably the most important point in OS/2 pre-history was the introduction of IBM Personal Computer (a complete lack of inventiveness when it comes to product naming, so typical for IBM) in 1981. The designers of the IBM PC unfortunately made one huge mistake - they grossly underestimated the popularity and impact of the PC. Of course blaming them for lack of foresight would be kind of silly. If they could see into the future, they could have made big bucks in the future prediction business and wouldn't need to bother designing computers. Anyway the original plan was to sell 250,000 PCs over five years. IBM in fact sold that much before the PC was even officially released! Not to mention in the next five years... And even now the PC architecture suffers from many design choices made twenty years ago. Again, that's not to say the choices were poor at the time when they were made, just that too much of a good thing (backwards compatibility) can be a bad thing.

The IBM PC had one feature that propelled it to unprecedented popularity: it was an open system. IBM published all the hardware specs and anyone could make add-on cards for the PC and even complete "clones". This soon created a huge market for all the new hardware manufacturers. The quality was often shoddy but the stuff was cheap and selling like hot cakes. This continues on until the present day. As they say, the more things change, the more they stay the same.

On the software side, IBM decided to contract a third party to write an operating system for the PC. The wonderful stories about how PC-DOS came to be the OS of choice for the PC have been told elsewhere. PC-DOS itself wasn't all that wonderful however. In fact calling any version of DOS an "operating system" is stretching the definition more than a little, and especially PC-DOS 1.0. But let's get back to the history. Just like the PC hardware, the software components were very open. The interfaces to DOS and the BIOS were well documented and it was easy for third parties to use and extend them. This enormous flexibility is the reason why DOS is still used even now for some tasks.

The DOS and BIOS interfaces unfortunately also had one major deficiency. They were not stellar performers and what's much worse, they didn't cover the complete functionality of the PC hardware (especially DOS was seriously lacking in this regard). This meant that to take full advantage of hardware capabilities, many application programs had to access the hardware directly, circumventing the DOS and the BIOS. This is a Bad Thing(TM) and came to haunt PC software and hardware vendors (and users) for years and years to come. More about this later.

OK, we're now in the early 1980's. The PC is a popular business tool, the software and hardware markets have exploded and practically everyone sells some gizmos and nifty utilities for the PC. But PC users are not quite happy (OK, humans are never quite happy but that's besides the point, because that's built in). They actually have good reasons for this unhappiness:

Some of these problems could be perhaps solved purely in software with a better designed operating system. But others needed hardware-augmented support for the solutions to be efficient. This improved hardware hit the market in 1984 and was called the IBM AT (Advanced Technology). It really was a lot more advanced than the PC and XT class machines. The entire hardware architecture received a major overhaul. The ISA bus was extended to 16-bit (from 8-bit), there was a built in real-time clock, high-density floppy drives, better harddrive support, more interrupt channels (IRQs), more DMA channels and so on. Many aspects of the PC architecture have not significantly changed since the AT. Some because the hardware simply matured (there's only so much you can do with a real-time clock for instance), others (like the interrupt controller) stay around due to the requirement for backwards compatibility which has since become the biggest boon and curse to the PC industry.

But perhaps the most significant advance was realized by the CPU. The IBM AT sported the Intel 80286 CPU (with 6MHz frequency compared to 4.77MHz 8088 CPUs in the PC). The 286 was still a 16-bit CPU just like its predecessors but had one major new feature: the protected mode of operation. The 8086 only had one mode which would later be called "real mode" (probably because all memory addresses correspond to "real" physical memory locations, unlike in protected mode). After startup, the 286 ran in real mode, (almost) fully compatible with the 8086 only faster and with a slightly larger and improved instruction set. It could address 1MB of memory just like the 8086 - actually the 286 could address 1MB + 64KB but that's not important here. In protected mode however it could address a whopping 16MB of memory - that was a lot considering that PCs with 16MB RAM became common more than ten years later. But even better than the vast memory addressing capability, the protected mode was, well, protected. This means that memory access wasn't "free for all" -  instead, there were four levels (or rings) of protection and less privileged code couldn't clobber memory belonging to more privileged components. This meant that user code couldn't accidentally or deliberately overwrite operating system code and also applications were protected from each other. Likewise some CPU instructions were now restricted and could only be executed by code with sufficient privilege, such as the OS kernel or device drivers. An attempt to breach the protection triggered an exception which would be intercepted by the OS - that would typically terminate the offending application. All the protection checks were performed in hardware with minimal runtime overhead.

Both IBM and Microsoft fully realized the problems inherent in the real-mode DOS architecture and worked on solutions throughout early and mid-80's. There were two significant products that made it to the retail shelves:

Both these products extended DOS in significant ways but at the same time, being built on the shaky foundations of DOS, each suffered from its many shortcomings.

At the same time Microsoft (I don't know about IBM) was working on a whole new operating system designed to replace DOS. As early as January 1983, Microsoft started work on a multitasking version of MS-DOS which was intended to replace the real-mode single-tasking versions. This project kept changing names like crazy. First it was called DOS 3.0 (DOS 2.x was current at that time). But then Microsoft shipped DOS 3.0 as we know it and the project was renamed to DOS 4.0. Microsoft in fact did ship a version of multitasking real-mode DOS 4.0. If you think that's wrong... well, you're wrong. There was another DOS 4.0 shipped later (in 1989) which continued the line of real-mode single-tasking DOS. This "special" version of DOS 4.0 was allegedly only sold to some European OEMs and was never intended for end-users. I've also seen this version of DOS 4.0 being referred to as eDOS. At any rate after the work on the "real" DOS 4.0 started, the advanced version was again renamed, again with a complete lack of foresight, this time to (you guessed it) DOS 5.0. And yet again, this was not the final name. Instead, in August 1985 IBM joined the project and signed the Joint Development Agreement with Microsoft which gave both companies ownership of the resulting product. After a while the project was renamed to CP/DOS - this stood for Control Program/DOS and was an obvious pun on PC-DOS. But, as if there weren't enough name changes, CP/DOS wasn't the final name either. Not too long before the release, the product was renamed to OS/2 - probably to match the new IBM product line, the PS/2 (no, that's not Playstation, it's Personal System/2). This name in my opinion caused more harm than good because it gave people the completely wrong impression that OS/2 somehow required IBM hardware to run. Perhaps it was deliberate IBM tatctic as IBM touted OS/2 (not yet released) as one of the reasons why people should buy PS/2s. As if there weren't enough names, other names OS/2 had during its development stage were 286DOS (which made sense in a way), ADOS (Advanced DOS) and BigDOS.

The PS/2 itself was an interesting beast. So interesting that it deserves its own sidebar. But I'm digressing again, back to CP/DOS, er, OS/2. The first version of OS/2 was released in December 1987. Supposedly it was nearly complete in late 1986 but with the impending release of PS/2 (April 1987), IBM decided to delay the release and work on PS/2 support. From some angles OS/2 strongly resembled DOS and from others it didn't look like DOS at all. The command line interface of OS/2 1.0 looked a lot like DOS. All the familiar commands like DIR, COPY, DEL and so on were there. But the internals were extremely remote from DOS. In fact OS/2 broke very significant new ground and introduced to the PC many advanced features previously only found in larger systems. I don't know whether IBM or Microsoft influenced the design of the OS/2 kernel more (probably IBM). I do know however the names of the lead architects of OS/2: on the Microsoft side it was Gordon Letwin and on IBM side Ed Iacobucci (later the co-founder and CEO of Citrix).

It is interesting that OS/2 1.0 did not implement all features designed for it because of time constraints (again, some things never change...). The most obvious missing feature was the Presentation Manager (codenamed Winthorn during development) but there were a number of other less visible features missing which were later implemented in OS/2 1.1 and 1.2, such as installable file systems (IFSs) or named pipes.

OS/2 1.0 was indeed a radical departure from DOS and had a number of important features that DOS could never have - and which many other OSes began to support only many years later.

Perhaps the worst obstacle that the designers of OS/2 faced was DOS support. This was caused by a combination of several factors: None of these problems was insurmountable but their combination was deadly. You could say IBM and Microsoft had to pay for the follies of their youth - the initial design choices made in 1981. And of course the immense popularity of DOS came back at them like a boomerang - they just had to support DOS for OS/2 to have any chance in the marketplace at all.

The OS/2 developers actually considered a way to run DOS applications in protected mode but there were too many problems with that approach. The final design they settled on was to have a single fullscreen DOS session that would not execute in background - the OS/2 programs on the other hand still continued to run even when the DOS session was active. This required frequent switching between protected and real mode (if the DOS session was in foreground) which in turn required some extra work to make the performance acceptable. One example of the extra effort needed was with device drivers: they had to support dual mode operation, ie. they had to run in both real and protected mode to keep the number of mode switches down.

The DOS code in OS/2 was undoubtedly based on actual source code used in MS-DOS/PC-DOS but with many modifications. The file system code for instance was protected mode only - that is, for file access the OS had to switch to protected mode. This however became a big plus later when installable file systems were introduced: the OS/2 DOS box had no problem accessing files on a HPFS volume for instance.

All the protected mode code on the other hand was brand spanking new with all those nifty features listed previously. The kernel and system DLLs were written almost exclusively in assembly language for two reasons:

Now let's take a look at the actual OS/2 1.0 package. I am a proud owner of four original IBM 5.25" HD floppies (thanks John!). They are actually labeled pre-release but to my knowledge contain the actual 1.0 release code. The contents in many ways resemble DOS. The OS/2 loader and kernel are two hidden files named IBMBIO.COM and IBMDOS.COM, respectively - only IBMDOS.COM is much bigger than the DOS version, about 250KB. There are all those familiar external commands like FIND, SORT, SUBST, BACKUP, XCOPY etc. But there are also some strange utilities like TRACE or CREATEDD - yes, OS/2 1.0 could already perform system trace and memory dumps. Plus there is a bunch of those weird .DLL files like DOSCALL1.DLL, VIOCALLS.DLL and so on. There was nothing even remotely similar in DOS. Examination of those modules reveals one interesting fact - the description strings in many of them look like this:
IBM Personal Computer DOS  Version 0.00  SesMgr
- that's from SESMGR.DLL. I told you the final name changes came late in the development cycle.

In OS/2 1.0 there wasn't really much to look at. The interface was text only - the promised Presentation Manager was still not finished and customers really wanted something to play with. As I mentioned earlier, it strongly resembled DOS. But after hitting Ctrl-Esc the Program Selector appeared. It allowed users to switch between sessions as well as start new sessions. The Program Selector looked like this (this is a screenshot from the OS/2 1.0 tutorial program):

The theoretical maximum was 16 sessions but because the OS already occupied a few of them, the real limit was 12 user sessions. But that's still 11 sessions more than plain DOS - and probably not much of a limiting factor anyway because there are only so many tasks humans can do at the same time. The original plan was to run Presentation Manager as a single session (or Screen group) under the Program Selector but in actual implementation the functionality of PM and the task switching shell was merged, resulting in PMSHELL. Not the best decision if you ask me... but IBM and Microsoft of course didn't ask me. Back in the late 1980's I couldn't provide a whole lot of valuable input anyway because at that time I wasn't even sure what a PC was and I had certainly never heard of OS/2. I did find computers very interesting however - as long as I could play cool games on them (in my defense I should say that by that time I had already started to dabble in BASIC on 8-bit micros).

The Program Selector was customizable and even had online help (again a screenshot from the tutorial):

The lightweight text-mode shell TSHELL for OS/2 2.x is obviously modeled after the ancient Program Selector.

The only somewhat sexy (OK, not totally unsexy) program supplied with OS/2 1.0 was the tutorial. It was actually kind of neat. The first screen looked like this:

How old is this blue logo screen anyway? The tutorial had two main sections - one presenting multitasking and the Program Selector and the other explaining some basic commands as well as the concepts of directories and files.

Taking these screenshots was an adventure in itself. Unfortunately I have not been able to install OS/2 1.0 at the time I was writing this. The tutorial program however does run under OS/2 1.3 as well as OS/2 4.5 (yeah, that's some backwards compatibility!). Unfortunately it insists on running in a fullscreen session. But not being the type who gets discouraged easily, I wrote two small programs that capture and display the screen. Thanks to the power of the OS/2 API it actually wasn't all that difficult. I can only shudder when I remember how this would be done under DOS.

Thanks to the generosity of Lewis G Rosenthal, I am now a proud owner of a vintage 286 machine which does run IBM OS/2 1.0. This also at least partially dispels the myth about IBM OS/2 1.x requiring IBM hardware, because this machine includes no IBM components whatsoever and is not even a typical AT class computer. The main system is a Hyundai Super-286C built in 1988, with 10 MHz Intel 80286 CPU, 1 MB onboard RAM and Award BIOS. Somewhat unusual for that era, it also has onboard LPT and COM port as well as a floppy controller. Because 1 MB memory is not enough to run OS/2, the machine has an expansion board installed, a DFI Megalith with 8 MB RAM. Permanent storage is taken care of by a huge (for a 286 anyway) Microscience 160 MB ESDI drive connected to a WD 1007V-SE2 controller. Video is only Hercules monochrome (with a matching Tandy VM-3 green screen of 1985 vintage and with incredibly slow phosphor) but that is quite sufficient for OS/2 1.0 which only runs in text mode anyway.

Installing IBM OS/2 1.0 on this baby was quite easy (once I overcame several initial obstacles that were entirely my fault) and OS/2 runs well on this system. The performance is naturally not exactly blistering - especially the harddrive is no speed demon - but it shows that preemptive multitasking with memory protection was quite feasible on an AT class system. And OS/2 still boots in under 20 seconds on this ancient machine which is more than I could wish for with eCS on my PIII box.

Later on I even got OS/2 1.0 running on my PIII-600(!) after some tinkering. For some reason OS/2 1.0 absolutely refuses to boot from floppy on faster machines. But when I installed OS/2 1.0 on a small 50MB IDE harddrive on the above mentioned 286, OS/2 booted from that disk even in the PIII! I only had to patch one driver (KBD01.SYS) to prevent a Trap 0 - this is the same problem that all 1.x versions of OS/2 have except for the latest releases of OS/2 1.3. Needless to say, OS/2 1.0 runs really fast on the PIII-600.

From a user's point of view, OS/2 1.0 had several deficiencies. Some of them were fixed in later 1.x releases, however some took longer to fix:

In the marketplace, OS/2 was facing an uphill battle (some things just don't change). Its acceptance was hampered by a number of factors: OS/2 FUD is nothing new really. Here's a quote from the column Environments written by Charles Petzold and published in PC Magazine (later accomplished FUDsters themselves) sometime in late 1987 or early 1988:
Now for a lecture. There's been a lot of disinformation about OS/2 circulated in recent months.  Most of this stuff apparently originates with the CEOs of companies who compete with Microsoft in the applications and languages market. Lazy press people who have never run OS/2 and don't know any better pass these falsehoods on to the public.
Has anything at all changed since then? Well, yeah - Microsoft drove most of those companies out of business.

On the whole, OS/2 1.0 was neither a smashing success (or we'd be all running OS/2 now) nor a total flop (or I wouldn't be writing this under OS/2 version 4.5). It did introduce a great number of new (mostly good) concepts to the world of PCs. Programming for OS/2 consequently required a great deal of adjustment, especially from DOS programmers who were used to the premise that the hardware was "theirs for the taking". OS/2 suddenly prevented applications from accessing the hardware directly and forced them to behave nicely. However, that was made a lot easier by providing a clean and powerful API. That the API was designed well is proven by the fact that most OS/2 1.x apps can still run years later on the latest versions of OS/2 as well as (to a lesser extent) Windows NT/2000 without any hassles associated with virtualization of DOS or Windows 3.x applications.

Most importantly perhaps, OS/2 1.x built a solid foundation for OS/2 2.0, which itself was a major stepping stone in the PC history. Most of the concepts introduced in OS/2 1.0 proved to be good and were not significantly changed in later releases. Hats off to the original designers and engineers at IBM and Microsoft.


Again, the book Inside OS/2 by Gordon Letwin provided me with some valuable insights into the inner world of OS/2.

The basis for my screen capture program was one of sample programs from the book Advanced Programmer's Guide to OS/2 by Thuyen Nguyen and Robert Moskal, published by Brady Books in 1989.

I found some interesting tidbits of information in the book Peter Norton's Inside OS/2 by Robert Lafore and (you guessed it) Peter Norton, published by Brady Books 1988.

All this information is accurate to my knowledge. As I have hinted above, I never actively used OS/2 1.x, hence there are bound to be omissions or errors in the text. If you were around in the 1.x days and have some extra information (or some interesting old software), I will welcome any comments at <MichalN@prodigy.net>.