OS/2 1.2 and 1.3

The Struggle for Attention—OS/2 tries but largely fails to attract users

OS/2 1.2 and 1.3 were developed at a time when the relationship between IBM and Microsoft was becoming severely strained. In late 1988, Microsoft started working on NT, initially developed as NT OS/2 (also known as as “Portable OS/2” on the IBM-Microsoft product roadmap) and ultimately released as Windows NT. At the same time, work was underway on a 32-bit OS/2 version (initially referred to as OS/2 386), eventually released by IBM as OS/2 2.0.

OS/2 1.1 was not nearly as successful as Microsoft and IBM had hoped and it was unclear how to proceed. The initial plan was to de-emphasize Windows in favor of OS/2, but Microsoft was reconsidering that decision when OS/2 failed to sell in large numbers. IBM, on the other hand, had nothing to gain from Windows and continued to push OS/2. At any rate, both companies continued developing OS/2.

OS/2 1.2

In late 1989, OS/2 1.2 was released. In some ways it was what OS/2 1.0 should have been, or at least implemented all the major features that IBM and Microsoft had been promising since mid-1987. The GUI was much improved and had a much cleaner and more modern look (later used by Windows 3.0). A major addition to the OS kernel was the support for installable file systems, or IFSs. The first IFS which shipped with OS/2 was HPFS, the High-Performance File System.

HPFS was designed from the ground up by Gordon Letwin, the Chief Architect of OS/2 at Microsoft. The new filesystem overcame most of the limitations of the FAT filesystem and made OS/2 more practical for use as a server system. Among the major features of HPFS were:

• No 8.3 file name limit. File names could be up to 255 characters long and the set of acceptable characters was larger than in FAT—among others, it included the space character.
• Support for Extended Attributes. Each file or directory could have up to 64K of Extended Attributes (EAs) associated with it. Any kind of information could be stored there, such as program icons, descriptions, cataloging information, etc.
• Support for large disks. While FAT volumes can only be up to 2GB large, HPFS supported up to 64GB volumes, although this theoretical limit was severely restricted by the disk drivers at the time.
• Resistance to fragmentation. While FAT drives needed to be regularly defragmented to prevent sometimes very noticeable loss of performance, HPFS tried to allocate contiguous space for files, keeping fragmentation to a minimum.
• Minimal allocation waste. The largest-sized 2GB FAT volumes allocated space in 64KB clusters, leading to massive disk space waste (easily 50%), whereas HPFS allocated 512 byte sectors, thus minimizing the losses.
• High damage resistance. If the FAT table on a FAT volume was destroyed, the remaining data became a pool of digital goo because all of the allocation information was stored in the FAT. HPFS, on the other hand, duplicated some of the information and kept the disk structures doubly linked (i.e. linked in both directions). This scheme guaranteed that if one area of the disk was damaged, the data loss could be localized to that area of the disk. Even if a directory sector was damaged for instance, the files in that directory could still be recovered.

There were two versions of the HPFS filesystem available: the “plain” HPFS and HPFS386. The latter was included with Microsoft LAN Manager (and IBM LAN Server), was considerably faster, allowed much larger cache sizes and had several extensions suitable for servers, such as built in Access Control List (ACLs) and directory limits. Moreover, it was specially enhanced performance-wise for file server use.

There are rumors that Letwin in fact wrote HPFS386 first and the “lite” version of HPFS was derived from that. Both IBM and Microsoft clearly saw that FAT just wouldn’t do and decided to write a new filesystem. Each of the companies developed its own filesystem and then both were benchmarked to determine which was faster. HPFS won. Unfortunately it later turned out that it was the 386-only version written in assembler and after rewriting it in C so that it could be used on 286s as well, it was no faster than IBM’s prototype filesystem.

It is interesting that FAT was known to be more of a liability than an asset even in the 1980s, but Microsoft stuck with it well into the 1990s and beyond. The problem with FAT is that it was designed for low-capacity floppy disks—it was developed by Bill Gates and Marc McDonald in 1977. “When applied to fixed disks, however, the FAT began to look more like a bug than a feature”, to quote an article by Ray Duncan (the author of several excellent books on DOS and OS/2 programming) published in the September, 1989 issue of Microsoft Systems Journal.

The test system for OS/2 1.2 was again a Celeron 300A with 64MB RAM, ATI Rage 128 AGP graphics card and a 4GB IDE harddrive. OS/2 1.2 had the same problem as the earlier versions with KBD01.SYS crashing; the problem was fixed in much the same manner. Apart from that hurdle, the installation was smooth. After installation, users were greeted by the face-lifted Desktop Manager:

The similarity with Windows 3.0 (released several months after OS/2 1.2) was unmistakable:

Many of the fonts, icons, and GUI widgets were identical and the color scheme was very similar. The big difference between OS/2 and Windows was that Windows 3.0 ran on top of DOS and in fact could even run inside the OS/2 1.2 compatibility box (the Windows 3.0 README mentioned that feature). The other difference was that Windows came with a large selection of device drivers compared to OS/2′s spartan device support, as well as with a wide range of applets (of questionable utility, apart from Solitaire). OS/2 was much more businesslike and felt somewhat bare in comparison. That may have been one of the reasons why Windows gained much wider acceptance among end users.

OS/2 1.3

The success of Windows 3.0 was the final blow to the IBM-Microsoft partnership. In the mid-1980s, Microsoft knew they needed IBM, or at least couldn’t compete against a different company blessed by IBM. In 1990, Microsoft felt increasingly constrained and at the same time strong enough to continue on their own. Therefore Microsoft focused on Windows 3.0 and NT, while IBM continued developing OS/2. Microsoft still had numerous OS/2 related projects in the works (LAN Manager, SQL Server, etc.) but the platform strategy was now firmly centered around Windows.

OS/2 1.3 was developed primarily by IBM. There were no major new features, in part because OS/2 2.0 was looming large on the horizon. The code was straightened out and slimmed down, reducing memory requirements and increasing performance. IBM was still selling OS/2 with PS/2 machines, preferably in large batches to corporate customers, and it was business as usual.

In the Microsoft camp, things were rather more interesting. The long-term strategy was clearly all-Windows, but that posed serious short-term difficulties. Microsoft needed a platform for their server products, LAN Manager and SQL Server. DOS was clearly not viable for that purpose and Windows NT was a long way off (eventually released in mid-1993). In the interim, Microsoft needed OS/2 even though it was now an “enemy” product. The project known as codename Tiger was Microsoft’s version of OS/2 1.3, sold by Microsoft directly instead of through OEM channels (as the case had been with previous releases of MS OS/2 and MS-DOS.

Because Microsoft’s OS/2 1.3 was primarily intended as a server platform for LAN Manager, Microsoft developed a new disk driver architecture called LADDR. That made it easier to support the new crop of advanced disk controllers, mostly using SCSI. LADDR was the only significant difference between the IBM and Microsoft releases of OS/2 1.3.

IBM released OS/2 1.3 SE on November 30th, 1990, with the EE version scheduled to follow on December 31st. Among the new features was increased performance and reduced memory consumption (2MB RAM minimum, compared to 2.5 MB for OS/2 1.2), REXX scripting language support in both the SE and EE versions, Adobe Type Manager (ATM) with a core set of fonts, and an improved printing subsystem.

Applications

Major ISVs were slow in releasing Presentation Manager versions of their flagship applications. In part it was because they were slow in recognizing the importance of GUI environments (Lotus, WordPerfect), in part Microsoft was to blame for making the Presentation Manger API very similar in concept to the Windows API, yet maddeningly different in details. As a result, ISVs who already had Windows applications found it non-trivial to port those to OS/2.

There was, however, one company which offered a reasonably large variety of OS/2 applications: Microsoft. There was an OS/2 version of Excel, now in version 3.0.

There was also a PM version of Microsoft Word, separate from the character-based Word 5.5 which also ran under OS/2.

Microsoft’s development tools had good OS/2 support, and many (if not most) of Microsoft’s developers used OS/2. Even the initial development work on NT was done under OS/2 1.2. All of Microsoft’s professional development tools supported OS/2, both as a host and a target platform.

WLO

Microsoft recognized early on that the API incompatibility between OS/2 and Windows was a significant problem. Microsoft and IBM positioned OS/2 as a high end operating system and a successor to DOS/Windows, but developers found it difficult to write software that could run on both Windows and OS/2 Presentation Manager. The PM windowing system was very similar in concept to Windows, based around windows and messages (both were designed by Microsoft, after all), but there were numerous differences—such as inverted coordinate systems—which prevented easy portability.

In hindsight, this was an important design mistake Microsoft had made. However, at the time when the Presentation Manager was written, its developers saw it as an opportunity to fix and improve the Windows API; source (let alone binary) compatibility wasn’t a concern. Microsoft learned from this mistake and when Windows NT was released, it was possible to run many existing 16-bit Windows applications directly, and the Win32s compatibility layer was also available to run 32-bit applications on top of Windows 3.1.

For OS/2, Microsoft’s solution was WLO (pronounced ‘Willow’), a set of libraries providing a Windows API compatibility layer on OS/2. The idea was to let developers recompile a Windows application, link it against the WLO libraries, and thus create a native OS/2 Presentation Manager application.

Some people at Microsoft recognized the need for a portability layer as early as 1988, before OS/2 1.1 was even released. At the time, the layer was deemed unnecessary and counter-productive, because the number of existing Windows applications was tiny and there was fear (quite possibly justified) that the layer would lead developers to write only to the Windows API and ignore the Presentation Manager.

In the end, WLO 0.9 was released in February 1991. At that time, it was too little, and far too late. However, Microsoft successfully used an incarnation of WLO to port its own Excel and Word applications to OS/2 1.2/1.3.

WLO was documented in the Windows 3.0 SDK, but by the time ISVs had a chance to use it, Microsoft had already decided to drop OS/2. One may only speculate why IBM wasn’t interested in taking over WLO. Aside from likely licensing issues, IBM was probably far more focused on the vertical market where cross-platform portability was not a concern.

In the end, limited DOS compatibility and dearth of native Presentation Manager application made OS/2 1.x an unattractive operating system for general desktop use, even though it was used in a number of turnkey vertical applications as a multitasking, multi-threaded OS, a much more solid platform than DOS, with or without Windows.