OS/2 Research Outline

This is a set of wiki pages dedicated to researching the rise and fall of OS/2, with the intent on creating a larger record of the 16-bit and early 32-bit era of IBM's ill fated operating system, with stream ideas, research notes, discussion and more.

This is an effort to fundamental answer is to document the reasons as to why despite IBM's best efforts, OS/2 failed in the marketplace in favor of Windows 3.0, an operating system that is technically inferior in almost all regards.

Goals Of This Project

The fundamental goal of this project is to create a pretty definitive guide to the early history of OS/2, including showing how it worked, functioned, and more as a primary source, and should interest remain, the creation of multiple realtime videos and/or documentaries to document one of the more pivotal moments of the late 1980s, and early 1990s.

This wiki page should use citations for all major facts and statements, as they will be cited in any video. It's expected that each top level section will become its own "realtime video" at some point.

Overview of the 16-bit Era of OS/2

Because the level of general knowledge of OS/2 is so low, a basic understanding has to be established about the 16-bit era needs to be established. The closest thing to a canonical document on this era exists at the OS/2 Museum, but setting up usable and working systems with native apps is essential ...

Understanding The Pricing Of Equipment for OS/2

OS/2 runs decently on maxed out equipment, but that's easily going into five figures or more. We need to figure out what was acceptable for a developer system in this era ...

It should be important to research what hardware each version of OS/2 may have run on. For example, CGA cards on the AT were pretty common. Understand how OS/2 behaved on low end hardware vs. Windows of the era.

Another important note is that OS/2 was created as a replacement to Microsoft's Xenix (a licensed port of AT&T). The chronology here should be determined to understand more factors of the OS/2 mess.

Things to research:

• OS/2-Xenix chronology
• Typical low, medium, and high end PC hardware of the era
• What, besides DOS, was actively used in this time period

OS/2 Pre-alphas and 1.0

The OS/2 Versions And History page contains additional information to this topic

Scan of page InfoWorld 1987

What was the actual intended goals of OS/2? It's often cited that OS/2 was intended to deal with the shortcomings of DOS, namely lack of multitasking and memory restrictions, but is this actually true?

It's known that Microsoft offered a $3,000 SDK and training materials which had basically everything you could want and more in a single box, but IBM based material is somewhat scant ...

Topics to be researched:

• Descriptions of OS/2 (or ADOS) as found in early programming reference manuals
• Comparison of early alpha versions of OS/2
• Relationship of early OS/2 to European DOS 4.0
• In-depth reading and review of the manual and more

Questions to be answered:

• What were the stated goals of OS/2?
• What was actually provided out of the box in 1.0?
• IBM marked OS/2 as a server - understanding the relationship here is important

OS/2 Editions

OS/2 1.0 Splash Description Page

Microsoft OS/2 Splash Screen Startup

In general, OS/2 was first created for IBM hardware, and then by Microsoft, resold for other PC compatible vendors. OS/2 was also available directly from Microsoft as an upgrade. There are known code and behavior differences between the two editions, as well as significant differences in documentation. However, all editions of OS/2 should be able to run the same binaries.

In general, IBM branded versions only ran properly on IBM machines or extremely compatible clones, while Microsoft versions were, for the most part, more forgiving.

IBM Edition

IBM editions are generally considered the "canonical" branch of OS/2, as they were developed for and used on IBM's PS/2 line of machines, which were generally the highest end machines with microchannel architecture support. If you were going to shell out the money for a MCA system in the late 1980s, you almost certainly were running either OS/2 or Xenix.

The question is, what did OS/2 specifically bring to the table for power users of this session. The canonical answer would be "Presentation Manager", but is PM actually that good?

Microsoft Edition

Similar to DOS of the era, Microsoft sub-licensed OS/2 to any OEM who wanted it, creating things like "Nokia OS/2" and "Intel OS/2". There are some code changes, possibly for compatibility reasons. It's likely that OS/2 was at least available for licensing for non-IBM compatible PCs, and may have had an actual OEM adoption kit, similar to the Windows 2/3 OAKs. While unlikely to ever turn up, a good look at the differences between editions is warrented. IBM OS/2 for instances uses the undocumented but highly commonly used 286 LOADALL instruction.

IBM Extended Edition

Although not sold to end-users, IBM also offered an special version of OS/2 to its partners and vendors, which included applications for use in big business, and more importantly, talking to expensive IBM hardware of the era. This had three essential components

• Communications Manager - allows interfacing to various IBM mainframes
• Database Manager - A SQL database that was later ported to UNIX as a non-mainframe version of DB/2
• LAN Requester - Client for accessing LAN Server/Manager and NetBIOS shares on the network. May not have been in OS/2 1.0 (need to check)

IBM OS/2 1.2 Extended Edition was also the first version to include REXX, before it became a part of every release starting with OS/2 1.3 (for both IBM and Microsoft).

LAN Manager

OS/2 was also a very popular server platform, completing with Novell NetWare, and UNIX systems of the era, and was in use well into the NT era. Microsoft sold their LAN Manager package as an add-on instead as a dedicated edition. Included were the following components:

• OS/2 LAN Manager Server
• OS/2 LAN Manager Workstation (or Requester in IBM parlance)
• DOS LAN Manager client software
• HPFS386 filesystem for OS/2
• Novell NetWare interoperability tools
• DOS and OS/2 Drivers for a number of NICs

It's unclear how much DNA is shared between IBM products and Microsoft ones.

OS/2 as a Server

One of the biggest roles of OS/2 in the 90s was its use as an application server, both for handling file and printer sharing, and was essentially the upsale from IBM PC LAN products of this time period. OS/2 was likely more suited as an application server than NetWare at the time, due to NetWare being monolithically linked, and only having "value addon packages", vs. the NLMs that came with NetWare 2.x.

Was the PC network of this era essentially just NetBIOS shares, or were there more functional aspects to it like using databases and more, and how did this interact with software of the era ...

Understanding the OS/2 Development Environment

Hello World and Example Applications on OS/2 1.0-1.3

The simplest application for a given platform is "Hello World", something I've documented extensively on both Windows, UNIX, and Linux in the past. OS/2's Hello World program has evolved as IBM replaced the toolchain (and tools) several time throughout the lifespan of the platform. Originally, IBM used Microsoft licensed tools, before replacing it with versions of CSet++ and Visual Age.

It's worth looking at the built in example applications from the varoius SDKs over the years to understand the full evolution of OS/2 from start to finish, especially in the era between IBM and Microsoft, as well as 3rd party toolkits that were commonly used such as Watcom.

Executable Format

16-bit OS/2 code uses New Executable (with e_lfanew value NE), a format shared with 16-bit Windows and multitasking MS-DOS. Note that OS/2 is numbered 1 in the OS field of the NE format (0 is unknown), suggesting the format was originally developed for OS/2, despite it being introduced with Windows 1.0 in 1985, two years before the first release of OS/2.

32-bit OS/2 code uses a new format called Linear Executable. Again, for maximum confusion, there are two incompatible versions of this format. The first one, with e_lfanew value LE, is used in pre-release versions of OS/2 2.0 (TODO: in which?), as well as in 386 version of Windows for native drivers. In OS/2 2.0 RTM, LE support was dropped, and the second version (with e_lfanew value LX) was introduced. This continued to be the format for 32-bit OS/2 executables up to Warp 4.52.

NE, LE, and LX executables all support dynamic linking, and all start with an MZ DOS stub that can run on DOS. A DOS version of the application can be put into the stub, most commonly, it just displays a message saying the program requires OS/2.

Comparison to DOS and Creating Family Mode applications

OS/2, especially in its earlier forms of ADOS or CP/DOS, was intended as a successor of DOS. Migration facilities like the DOS window were intended to make it possible to migrate over time to OS/2, and there's support for what are known as "Family Mode" applications, which are OS/2 binaries that use a subset of system calls (documented in the IBM OS/2 Technical Reference), and can also be run on a DOS system.

This is different than the DOS stub in NE and PE headers (https://en.wikipedia.org/wiki/New_Executable). In the case of a family mode binary, the binary ran the same on both platforms, with a specialized stub being provided that implemented the OS/2 functions on DOS. When a family mode binary was executed under DOS, the stub linked the NE executable against its own DOS implementation of the Family Mode API and ran it. Because of this, startup of family mode binaries under DOS is slower than for native DOS binaries.

To create a family mode binary, a regular OS/2 binary is created first, then the BIND utility (shipped with Microsoft C) is applied, which adds the necessary DOS stub. If the binary contains calls not supported in family mode, BIND will exit with an error specifying the calls.

Family mode binaries were fairly rare, but Windows NT will always default to using a OS/2 mode binary over a DOS binary unless the FORCEDOS command is used.

GDI vs GPI (and other API differences)

One of the largest differences between OS/2 and Windows is that the graphics API was entirely replaced. Presentation Manager (OS/2's GUI), was at least in part based on Windows 2.x, and shared many similar features. However, one important difference deals with the graphics API. Windows uses the "Graphic Device Interface" or GDI which is a device independent way of displaying graphics. It originally dates to Windows 1.0, and is still present in Windows 11. OS/2, among other things, replaced with GPI, or "Graphics Precision Interface", and moved the location of 0,0 to the upper left most corner.

There are other differences in OS/2 applications, such as how functions and other parameters that it might be beneficial to go through and at least document at least some of the differences, and try and understand why they may exist.

Windows Libraries for OS/2

This section had a full wiki page Windows Libraries for OS/2 for more information

Dr. Shuppet has done an amazing job at writing up the history and backstory of WLO, which is a port of Windows libraries running under Presentation Manager. WLO was several compatibility solutions, such as Micrograx Mirrors. Microsoft shipped ports of the Windows 3.0 accessories as a WLO demo, and several OS/2 native binaries, such as Word and Excel for Windows use WLO or similar technologies to bridge the gap between Presentation Manager and the Win16 API.

WLO was obviously intended as a transition technology when Windows started gaining momentium in the 2.x and 3.x days, but before the IBM-Microsoft divorce was finalized, and should be categorizes in the great timeline of events.

Exploring Native OS/2 Apps

While OS/2 didn't have a lot of apps, it did have decent first party support from Microsoft in its early days, as well as a couple of dedicated apps such as the DeScribe word processor and more. By and large, OS/2 had a small set of productivity apps, and some DOS and Windows ports, but was relatively sparse. Furthermore, due the the inherent problems of Presentation Manager, Win-OS/2 apps were sometimes preferable since they couldn't deadlock the system like native PM apps could due to the Single Input Queue (SIQ).

IBM created a list of applications for OS/2, which is now stored at OS/2 World Wiki.

By and large, IBM did define the Common User Access Guidelines throughout this era, which was similar to Apple's Human Interface Guidelines, so it's generally expected that OS/2 native applications may have a more consistent look and feel. At the time of writing, it's unknown if there were any good frameworks like MFC or OWL for OS/2 ...

Limits of Preemptive Multitasking

OS/2 is a natively preemptively multitasking system; it shouldn't be possible for a single application to hang the system. However, this isn't true in practice. For what were presumably performance reasons, OS/2 Presentation Manager applications share what is known as the Single Input Queue (also written as Single Event Queue), which is a message pump shared between all applications, and is inherited from Win16 programming.

The fundamental end result of the SIQ means that one crashed Presentation Manager application can hang the entire UI with startling ease. A partial fix for this, the async SIQ wasn't released until OS/2 Warp 4, which was near the end of OS/2's commercial life span. While it is possible to disable Presentation Manager through editing CONFIG.SYS, or even use the OS/2 1.0 TSHELL.EXE, this doesn't appear to have ever been officially supported by IBM.

In theory, OS/2 should be fully capable of process and thread based multitasking similar to Windows NT, but documenting the full limitations is important. It's also worth checking (with a kernel/ICE debugger if necessary) if the the 286's task segment selector (TSS) is used in this process at all ...

Capabilities and Limitations of OS/2

There's a lot that's been written that tries to determine why OS/2 failed on a technical level, but it's difficult to determine if this was justified in fact or fiction. Some parts of this are people who are familiar with other operating systems, combined with relatively sparse documentation may cause people to have a lot of mistaken assumptions. Some of the major points to be researched and discussed follows.

How Hamstrung was OS/2 By the 286

One of the largest repeated beliefs is that OS/2 was hamstrung by the design of the 286. There's certainly reason to believe this, since NT was intended as "Portable OS/2", and the system remained a mismatch of 16-bit and 32-bit code to it's end. However the 386 was fully supported with MVDM by 1992, when OS/2 2.0 first shipped. In practice, the 16-bit versions of OS/2 seem very similar in capability to the 16-bit versions of Windows, and are arguably closer to Windows 9x than they are DOS.

The largest problem appears to not so much the protected mode of the 286, but the lack of a way to virtualize DOS (see below). The FOOTBALL demo, which uses V8088 mode on a 386 to provide DOS multitasking was available in 1986-87, although 386 systems would have been extremely rare at the time. OS/2 1.2 was essentially the feature complete release of the 1.x family, with 1.3 being more of a bug release, and parting of ways for Microsoft. Need to research this into a timeline.

It can be speculated that CPU license issues were behind the delayed release of the 386 version of OS/2. Allegedly, IBM did not want to rely on a single CPU vendor, which limited the possibility of adopting the 386, AMD's rights to which were subject to lawsuits that were only resoled in 1991.

HPFS

HPFS was intended as a replacement for the aging FAT (file allocation table) filesystem. Standing for High Performance File System, HPFS brought support for long filenames, and extended attributes to OS/2 1.2, and is required for many OS/2 applications to function properly. HPFS was also supported on NT 3.1 and 3.5, and later versions through the PINBALL driver. From what I know, NTFS is essentially an extension of HPFS, with similar data structures and more, but this should be looked more into by comparing the NTFS and HPFS drivers in the Linux kernel.

Use of Segmentation in Protected Mode (such as IOPL)

OS/2 is notable for being one the few operating systems to take advantage of the 286's segmentation-based memory protection model. It's one of the rare users of protection ring 2, which subsequent operating systems such as Windows NT chose to ignore for portability reasons. When being linked, applications could declare in the module .DEF file which of their code segments are IOPL segments (I/O privilege level). Additionally, CONFIG.SYS contains an IOPL directive that limits which applications allowed to use IOPL. IOPL=YES and IOPL=NO are used to enable or disable IOPL for all applications; the former is default on some versions of Microsoft OS/2 (TODO: which version? Seems to include 1.0, but not 1.3.).

This had several benefits. If applications separated IOPL code correctly, bugs in the non-IOPL segments wouldn't cause wayward I/O accesses. The design of the 286 encouraged this; calling the IOPL segment required applications to define call gates, which encouraged the use of a well-defined interface between ordinary ring 3 code and IOPL code. Also, since the IOPL segment ran in ring 2 and not in ring 0 (kernel mode,) it was still subject to memory protection and was not allowed to access memory that its process could not normally access. This includes kernel memory.

OS/2's use of segmentation could have, at least theoretically, let it support features like NX (No eXecute) on the 286, which would have provided a level of application hardening that didn't exist until decades later.

Unfortunately, as OS/2 was a single user operating system, there were limits on how much security could be obtained using segmentation. Perhaps research into this design decision is warranted, especially in places where user authentication is used.

Noteworthy uses of IOPL include:

• Word for Windows provides DE.EXE, as part of its UI designer that requires IOPL=yes to be enabled in CONFIG.SYS
• Multiplan
• other applications can do similar based on their manifest (although I need to check the LX format documentation)

Networking with NetWare/LAN Server/LAN Manager

Although mostly unknown by home users, both DOS and OS/2 supported network operations, leading to the term network redirector. From reading in the Windows NT Resource Kit, and other places, communication between applications happened in the form of named pipes, and IPC process namespaces. Its worth looking more in-depth how NetBIOS related networking works, as possibly part of a larger series on the value of the network. In many ways, OS/2 pioneered much of what would be the NT network stack, including being the home of domains and more.

Furthermore, NetWare Client for OS/2 1.1 has recently turned up, and a beta of NetWare for OS/2 1.0 has also recently shown up, so it might be worth taking these systems out for a spin.

DOS/Windows Compatibility

One of the largest criticisms was horrid backwards compatibility with DOS and Windows. The 16-bit versions of OS/2 could only run one DOS application at a time in what commonly became known as the penalty box, which was a DOS session that was constantly running. This is due to how the 80286 didn't provide any support for virtualizing real mode applications, and delays involving OS/2 2.x meant that 386 support didn't ship until 1991-92, well past Windows/386 and Windows 3.0.

There's a known prototype of OS/2 1.0 for the 386 called FOOTBALL which is archived on pcjs.org which does have multiple DOS applications, running through virtual 8088 mode. The notes included show that it was an internal demo meant to be shown to Bill Gates. There were relatively few native applications for OS/2, especially as compared to Windows, so compatibility was definitively something to be mindful of, as stores would have no or limited stock of OS/2 applications.

Later OS/2 Era Stuff Worth Researching

This is just a list of notes of things that should be researched as time permits, but is somewhat out of scope for the things planned.

• OS/2 on PowerPC
• Embedded OS/2 such as on the New York City Subway
• eCommStation and AcraOS
• IBM's use of OS/2 as the system controller for its mainframes well into the 2000s.
• The creation of VirtualBox due to the difficulty of running OS/2 inside of other emulation/virtualization software.

Anyone should feel free to contribute to this (or any other page) relating to OS/2 history.