Archives
- November 2025
- October 2025
- September 2025
- August 2025
- July 2025
- June 2025
- May 2025
- April 2025
- March 2025
- February 2025
- January 2025
- December 2024
- November 2024
- October 2024
- September 2024
- August 2024
- July 2024
- June 2024
- May 2024
- April 2024
- March 2024
- February 2024
- January 2024
- October 2023
- September 2023
- August 2023
- July 2023
- June 2023
- May 2023
- April 2023
- March 2023
- January 2023
- December 2022
- November 2022
- October 2022
- September 2022
- July 2022
- June 2022
- May 2022
- April 2022
- March 2022
- February 2022
- January 2022
- December 2021
- November 2021
- October 2021
- September 2021
- August 2021
- July 2021
- June 2021
- May 2021
- April 2021
- March 2021
- February 2021
- January 2021
- December 2020
- November 2020
- October 2020
- September 2020
- August 2020
- July 2020
- June 2020
- May 2020
- April 2020
- March 2020
- February 2020
- January 2020
- December 2019
- November 2019
- October 2019
- September 2019
- August 2019
- July 2019
- June 2019
- May 2019
- April 2019
- March 2019
- February 2019
- January 2019
- December 2018
- November 2018
- October 2018
- August 2018
- July 2018
- June 2018
- May 2018
- April 2018
- March 2018
- February 2018
- January 2018
- December 2017
- November 2017
- October 2017
- August 2017
- July 2017
- June 2017
- May 2017
- April 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- June 2016
- May 2016
- April 2016
- March 2016
- February 2016
- January 2016
- December 2015
- November 2015
- October 2015
- September 2015
- August 2015
- July 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
- January 2015
- December 2014
- November 2014
- October 2014
- September 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- December 2013
- November 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- January 2011
- November 2010
- October 2010
- August 2010
- July 2010
OS/2 1.0
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.
General Description
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.
Features
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.
Market Reception
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.
Installation
IBM’s OS/2 1.0 SE came on four high-density floppy disks, either in 51⁄4” or 31⁄2” 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.
Limitations
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.
19 Responses to OS/2 1.0
Very insteresting.
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.
Supporting the 80286 made sense when OS/2 started development in 1985, but by 1987, it was a poor choice for what was supposed to be the forward-looking OS *of the future*. As it stands, OS/2 was too heavy for most 286 systems and took poor advantage of 386s, being unable to do any decent DOS multitasking like Windows/386 and especially Windows 3.0. Also, Windows/386 could preemptively multitask DOS applications, just not Windows programs, and the DOS VMs were protected from each other.
There was clearly a major conflict between “forward looking” and “usable on PCs available at the time”, no question about that. Windows/386 is perhaps a good example… sure it could run DOS apps decently, but forward looking? With crummy multitasking and zero memory protection for Windows apps? Not really.
NT was definitely forward looking, and also too much of a memory and CPU hog many years after OS/2 shipped. So that’s a useful data point as well.
I am certain that if IBM and Microsoft had made different design choices, OS/2 would have been criticized just as much (if not more) for not having gone the other way.
And as a reminder, by the time OS/2 shipped, the 386 was barely capable of running 32-bit code without running into all kinds of nasty errata. The 386 was quite buggy initially but the vast majority of bugs affected 32-bit code only, which is of course how they went undetected.
This site uses Akismet to reduce spam. Learn how your comment data is processed.