The Next DOS—The designated successor to the world’s most popular OS
IBM and Microsoft announced OS/2 1.0 on April 2nd, 1987, with a projected shipping date in the first quarter of 1988. This was a break from the typical IBM policy of the time—new products were usually announced when they were ready to be shipped.
That April 2nd was an important day for IBM. The new PS/2 family of computers was announced—IBMs attempt to regain control of the PC market, a significant but ultimately unsuccessful endeavor. The name “OS/2” was clearly meant to be a fit for PS/2, emphasizing OS/2’s advanced features and implying that PS/2 and OS/2 were made for each other.
That was not quite true, however. Although OS/2 was able to take advantage of the PS/2 systems’ capabilities, the PS/2 machines were equally suited to run other operating systems, and conversely, OS/2 was never limited to PS/2 machines and supported AT-compatible systems from the beginning. In fact, the development of OS/2 started on IBM AT machines long before the PS/2 systems were available.
IBM and Microsoft had a strict division of labor in marketing OS/2, very similar to their arrangement in selling DOS. IBM was offering OS/2 directly to its customers and only provided support for IBM systems. IBM OS/2 was quite capable of non-IBM systems, as long as they were sufficiently compatible with the IBM PC/AT. That included peripherals—IBM offered no support for non-IBM graphics adapters or storage controllers.
Microsoft was not selling OS/2 directly to end users (not until much later) and instead worked with OEMs such as Compaq, Zenith, Tandy, Epson, AST, and others. It was the OEMs’ responsibility to adapt OS/2 for any custom hardware (in other words, write device drivers).
In a break with past and future tradition, OS/2 1.0 shipped earlier than initially announced—in December 1987 rather than in the first quarter of 1988. The list price for IBM OS/2 1.0 Standard Edition was $325, significantly higher than the $120 IBM was charging for DOS 3.30. OEM versions of Microsoft OS/2 followed with a slight delay in 1988.
The Name Game
The name of Operating System/2 has an unusually complex history. In early 1983, Microsoft started work on a multi-tasking version of DOS. Because the shipping version of DOS was 2.0 at that time, the future product was called DOS 3.0. When the actual non-multi-tasking DOS 3.0 was shipped, the project was renamed to DOS 4.o. The mythical multi-tasking MS-DOS 4.0 (sometimes called European MS-DOS 4.0) shipped as an OEM-only product in early 1986. It was a real-mode multi-tasking system and it certainly wasn’t OS/2. The protected-mode operating system project was now MS-DOS 5.0.
In June 1985, IBM and Microsoft signed the Joint Development Agreement (JDA), a generic agreement on future cooperation. In August 1985, the JDA was amended with a “Phase II” document, essentially a plan to develop OS/2. The product was referred to as CP/DOS—Control Program/DOS, in line with IBM mainframe product naming. At that time, the name OS/2 didn’t exist. The product was sometimes also called DOS 5 (especially at Microsoft), 286-DOS, or Big DOS. Some very old compiler libraries refer to DOS and OS/2 as DOS 3 and DOS 5, reflecting the old naming scheme.
Sometime in late 1986 or early 1987, the project was officially renamed to OS/2 to coincide with the release of the PS/2 line of systems; whether that was an improvement is questionable, because it confused some into thinking that OS/2 ran only on PS/2 machines. Initially, the name was sometimes spelled as OS|2 rather than OS/2 in third-party materials.
OS/2 1.0 was marketed as a successor to DOS, which was both accurate and misleading. OS/2 was not intended to be a clean break with the past (hence names such as DOS 5), rather it was meant to enable a gradual transition.
Significantly, OS/2 used the same FAT file system as DOS. Users could freely exchange data between DOS and OS/2 systems, and with dual booting, OS/2 and DOS could even coexist on a single disk partition. Even more significantly, users could run DOS application directly within the DOS compatibility session of OS/2. Through the Family API, it was possible to write dual-mode applications which could execute both under DOS and under OS/2.
Yet in other ways, OS/2 did not resemble DOS at all. One of the greatest differences was philosophical more than technical: Instead of the free-for-all world of DOS with very few vaguely defined interfaces and the resulting chaos, OS/2 provided a rich set of clearly defined and delineated APIs. Applications had to work with the operating system rather than create their own. The OS/2 API was far richer than the DOS programming interface, but it was comparatively harder to extend it. In that respect, OS/2 1.0 was much closer to modern operating systems than to DOS.
OS/2 1.0 was a 16-bit multi-tasking protected-mode operating system with pre-emptive scheduling, multi-threading, dynamic linking, and virtual memory.
Because OS/2 was a protected-mode operating system, it required at least a 286 CPU, although it was capable of running on 386 systems as well, albeit without taking advantage of any 32-bit features (except for HPFS386 in LAN Manager 2.0 and later). Much has been written about the difficulty of mixing a protected-mode operating system and real-mode DOS applications; the details will not be re-iterated here.
OS/2 fully utilized the segmented memory model of 286 processors with the accompanying memory protection capabilities. Up to 16MB RAM could be directly used; segment-based virtual memory (segment swapping) allowed much higher virtual address spaces. With OS/2 1.0, that was of course very theoretical with a 32MB partition size limit, although in an era when a powerful PC had 4MB RAM, it was not a practical restriction.
In OS/2, dynamic linking was consistently used to implement many operating system features. The entire OS/2 API was accessed through a set of dynamic link libraries (DLLs), and users could write their own DLLs.
OS/2 was one of the first multi-threaded operating systems on the market. All threads were pre-emptively time-sliced, with a fairly sophisticated scheduling algorithm (refined in later versions). With multi-tasking came also interprocess communication and synchronization primitives. OS/2 1.0 supported shared memory, pipes, queues, semaphores, and signals.
What OS/2 did not have was support for multi-user operation and multiple CPUs. The latter was not a practical problem, as multi-processor PCs were extremely rare before the mid-1990s. On the other hand, the lack of multi-user support was a real problem and prevented OS/2 from being used in certain markets.
When OS/2 was released, it was very modern and outdated at the same time. Features like multi-threading and dynamic linking were far from commonplace in 1987. Pre-emptive multi-tasking was something most Windows users had to wait for until 1995, and fully protected memory was only implemented in Windows NT.
Crucially, OS/2 1.0 provided no support for 32-bit applications and could not take advantage of the 386-based PS/2 and AT compatible systems already on the market. This was largely unfortunate timing—work on OS/2 was started when 386-based PCs didn’t even exist, and IBM and Microsoft decided that getting a 16-bit OS/2 on the market faster was better than skipping the 286 entirely and going only for the fledgling 386 market. That decision was probably correct in 1987, but for various reasons it took until 1992 to release a 32-bit version of OS/2; that may have been one of the most significant factors in the eventual demise of OS/2.
One of the more important consequences of the decision to support 286s was relatively poor compatibility with DOS applications. It was a miracle that OS/2 could run DOS applications at all, but the 286 limitations severely undermined both the compatibility and stability of OS/2. The 386 offered a Virtual-8086 mode (V86 mode) which made it possible to provide better compatibility without compromising stability, but that had to wait until OS/2 2.0; in the meantime, the V86 mode was used by Windows/386, DesqView, as well as several UNIX variants.
In the corporate market, OS/2 fared relatively well. It was a good platform for deploying vertical applications and for (relatively) small servers, but never managed to capture more than a few percentage points of the wider PC market as a whole. Of course one of more the significant factors was the fact that Microsoft ultimately abandoned OS/2 and IBM never depended on it.
IBM’s OS/2 1.0 SE came on four high-density floppy disks, either in 5¼” or 3½” format. Microsoft OEM versions varied, but four disks were typical. Only high-density disks were normally used, since all desktop PC/ATs and compatibles came with high-density drives.
Both the Install and Program disks were bootable; the latter could be used to run OS/2 without previous installation to a fixed disk. OS/2 1.0 was small enough that the OS itself and several useful utilities fit on a single floppy.
The installer was not particularly unusual. It enabled the user to partition and format a fixed disk, select several configuration options (such as the type of the attached mouse) and copied the files from floppies to the fixed disk.
Further text refers to Microsoft OS/2 1.0 as it was delivered with the Microsoft OS/2 1.0 Software Development Kit (SDK) in December 1987. This version was not available to end users (Microsoft only licensed OS/2 to OEMs), but accurately reflects the features and capabilities of MS OS/2 1.0.
The SDK version of OS/2 1.0 was installed in a VirtualBox VM with a few custom modifications. That made it very easy to take screenshots.
Differences from IBM OS/2 1.0 are noted where applicable.
Look and Feel
After installation, OS/2 1.0 resembled nothing more than DOS. The similarity was of course not at all coincidental, even though the internals of the two systems could hardly be more different.
The OS/2 1.0 user interface was deliberately very similar to DOS. Commands such as CD, DIR, or COPY were essentially identical, and the batch language was highly compatible. The DOS box provided a relatively high degree of compatibility with DOS, including the ability to run Windows 2.03. The OS/2 command interpreter (CMD.EXE) was only different from COMMAND.COM in areas where OS/2 specific functionality was exposed, such as command grouping and chaining (e.g. the &&, ||, and & operators).
The similarity between DOS and OS/2 also extended to features, or lack thereof. The only editor OS/2 1.0 shipped with was EDLIN, only usable in the DOS box and just as woefully outdated and difficult to use as in DOS.
A bare OS/2 1.0 installation did not immediately offer much advantage over DOS. There were no major additional productivity tools shipped with the OS. However, there was one major difference, the Program Selector.
The Program Selector was the multi-tasking shell which allowed the user to start additional sessions and unlock the multi-tasking capabilities of OS/2. Note that the DOS box was always present, unless it was entirely disabled via a CONFIG.SYS setting. Only one DOS session was available, a drawback which only changed with OS/2 2.0.
Software developers were among the first users who reaped the benefit of multi-tasking. It was easy to set up several sessions with editors, compilers, and other tools, all operating simultaneously. It was trivial to compile one project (even with a 386-based system, building a relatively small program could take a considerable amount of time) and at the same time edit a different project.
OS/2 also included debugging and introspection tools unheard of in DOS. The OS came with a trace facility which made it possible to follow the execution of predefined trace points. There was also a system dump facility, analogous to a UNIX system crash dump feature. A debug kernel was available as part of a separate Device Driver Kit (DDK).
Except for the Program Selector, OS/2 1.0 itself did not offer major improvements to the average user. However, OS/2 1.0 was a multi-tasking system and its API was far more structured and modern than anything DOS offered. OS/2 1.0 was important as a platform rather than as a stand-alone product.
IBM vs. MS OS/2
IBM’s and Microsoft’s versions of OS/2 1.0 were very similar and nearly 100% compatible, but not identical. Some of the differences were the obvious result of the way IBM and Microsoft divided the market—for instance, Microsoft OS/2 did not include any drivers for PS/2 systems.
Some of the differences were less easy to understand. IBM and Microsoft shipped different end-user documentation with their respective systems. Microsoft had to provide the documentation to OEMs to allow them to add to or modify the materials to reflect any OEM-specific changes, although most OEMs reproduced the documentation more or less verbatim. IBM had different documentation standards and produced its own documentation, very similar to Microsoft’s in content but in somewhat different style.
Then there were arbitrary and gratuitous differences. That included the names of the system files (OS2BIO.COM and OS2DOS.COM for the loader and kernel in MS OS/2, versus IBMBIO.COM and IBMDOS.COM in IBM OS/2, a holdover from DOS) and different system directory layouts. Microsoft used separate \OS2\BIN, \OS2\PBIN, and \OS2\RBIN directories for dual-mode, protected-mode, and real-mode executables, respectively. IBM simply lumped all executables under \OS2.
IBM and Microsoft releases of OS/2 1.x converged over time and each following version removed some of those differences. At any rate, very few applications noticed any difference and OS/2 based products had no specific vendor requirements.
Not surprisingly, OS/2 1.0 had a few limitations. Some of them were fixed relatively quickly, some took longer, and some were never fixed.
- Limited to 16MB RAM, in theory; in practice, OS/2 1.0 crashed during boot with more than 8MB RAM. This was not a serious issue in 1988 when systems with more than 4MB memory were extremely rare. OS/2 1.1 could utilize 16MB RAM, OS/2 2.0 could use much more.
- Limited to 32MB fixed disk partitions. This was a practical problem at the time of the release of OS/2 1.0, solved in OS/2 1.1.
- Limited DOS compatibility. A hardware restriction rooted in the requirement for support of 286 systems, solved in OS/2 2.0.
- No networking support. Solved with the release of LAN Manager in late 1988.
- No multi-user support. A conscious design decision, never changed.
The lack of a GUI was effectively a limitation (for some users at least), but at the time OS/2 1.0 was released, firm plans for a GUI-based version 1.1 had been already announced.
In many ways, OS/2 1.0 was a ground-breaking and very modern operating system. Looking back at the history of PC operating systems between DOS and Windows NT, OS/2 1.0 was much closer to DOS on the surface, but much closer to NT when overall system design is taken into consideration.
Is it possible, to make a tutorial, how can I run OS/2 1.0 in a VM?
With best regards
Thanks for the excellent website. I have never had success running os/2 1.0 in any virtual system, and your post here does a great job explaining why. I will begin to search for the SDK version that you mention on ebay. Any tips about the modifications to Virtualbox that you used?
Yes, but right now it’s unreasonably difficult. I’ll wait until VirtualBox includes the required fixes and then explain how OS/2 needs to be patched to run. Give it a month or two.
Good luck finding the old SDKs – if you do manage that, please let me know!
Instead of describing the required modifications, I’d rather get them into the official releases 🙂 It’s going to take a while but hopefully not too long.
“Limited to 32MB fixed disk partitions. This was a practical problem at the time of the release of OS/2 1.0, solved in OS/2 1.1.”
Yea, it came from DOS 3.x and was solved on the DOS side by Compaq DOS 3.31 and DOS 4.x.
How did it come with DOS 3.x? Every version of DOS before 4.0 (and Compaq’s 3.31) was limited to 16-bit logical sector numbers, which directly caused this limitation (65,536 * 512 bytes = 32MB).
“That decision was probably correct in 1987, ”
Yea, note that the 386SX (386 with 16-bit 286 compatible bus that made it much cheaper) was not released until 1988.
Somebody was mentioning the SDK for OS/2. I have access to the Microsoft OS/2 SDK 1.02 if somebody was interested.
See here – though I’d be interested in things like cover letters and packing lists.
Pingback: Microsoft Windows/386 | Electric Thrift
Thank you for the interesting article. I have a MS Prof Basic with a very nice IDE workbench in it that allows you to run 32 bit protected mode apps written in the BINP mode. I did get the IBM 1.30.2 version (hoping that would be compatible with the MS OS/2 ) and run the workbench in the protected mode. I want to install it stand alone in a Symantec partitioned multibooting environment. I have no manuals with the OS/2 diskettes. I am looking for the Getting Started and the User’s Guide manuals either IBM or MS. Is there any one out there who had done this or could help me with the manuals? Many thanks.
I could help you with manuals for (MS) OS/2 1.0 or 1.1. Don’t have anything for the later editions scanned I’m afraid.
I have a 1 os/2 in sealed sale who cares box. Offer [email protected]
The 32 MB partition limit was true with Version 1.0 from SDK and IBM OS/2 1.0 SE.
I think you’ve got that slightly backwards. Only the “server adaptation” (SA) versions of the OS/2 1.0 kernel supported larger partitions, while regular OEM releases of OS/2 1.0 did not. My OS/2 1.0 EE doesn’t either.
windows 386 did thing that os/2 1.0 could not do
It also required a 386. On the other hand, OS/2 1.0 supported memory protection, pre-emptive multitasking applications, and multithreading — something which the Win386 line of operating systems had to wait for until 1995.