OS/2 a quarter century on: Why IBM lost out and how Microsoft won
Let's pile into the DeLorean to see what might have been
The Empire Strikes Back
The new 32bit OS/2 took advantage of several features of Intel’s 386 processor: a flat memory model and the ability to virtualise DOS sessions, yet maintain process communications between them. The 32bit version also supported the whacky DOS memory extenders, gave DOS applications fast 32bit disk I/O without them realising it, and once in a crash-proof OS/2 virtual session, the DOS application ran better than before. Both IBM and Microsoft were justifiably proud of this. IBM took Microsoft’s Flight Simulator – one of the most demanding graphical DOS games – and started one instance after another, until a dozen were running concurrently. All just kept ticking along.
All of a sudden, OS/2 looked a far, far superior product that answered many of the problems DOS had caused business customers for years. It even ran Windows programs faster than DOS could, and in multiple virtualised sessions. So OS/2 offered the the best of all possible worlds: old DOS apps with their skills base and third party add-ons, the newer wave of graphical Windows apps, plus native OS/2 apps.
There were delays, however. IBM had decided to add spruce up OS/2 with a radical new shell, called the Workplace Shell. It was more than just a UI chrome, but a set of object-oriented class libraries which could be overridden or extended by a developer. The Workplace Shell allowed OS/2 to do some of the tricks of the Mac, and plenty more of its own. It also gave it a radical feel that still startles to this day (see the Box out on page 5: WPS – WTF?!?). Bizarrely, OS/2 was gathering an evangelical grassroots support, thanks in no small part to the extraordinary demonstrations of IBM’s David Barnes, one of the industry’s great demo-gods. Here’s Barnes in full flow in 1993:
Microsoft needed a story, so it cast around and found one. This was a new multi-user portable operating system still in the very early stages of development, and it would prove decisive. It was called OS/2 version 3.0, or OS/2 NT - and it would be the most powerful piece of vapourware ever created. In 1990 this barely consisted of more than a bootable kernel; it would be three years before anyone could buy it, and six before it gained any traction. But it changed perceptions significantly.
RISCy business and the Unix-killer
The fact that this new OS was portable to different chip architectures was seen as very important. The conventional wisdom was that Intel’s processor architecture had run out of steam, and RISC chips were the future. New RISC processors from MIPS and Sun (Sparc) led the workstation field, with even late-comers like DEC (Alpha) and IBM (Power) obliged to follow suit. It would be hard to pick a winner.
Yet the new vapour platform also promised to deliver something that the warring Unix vendors should have, but didn’t: a unifying platform, with rich APIs. The Unix vendors perpetuated a tyranny of small differences. They fought bitter wars over tiny details irrelevant to most users. They plotted and schemed, partnered and divorced, ditching much of the most attractive work (like Sun’s NeWS Display Postscript UI) in a futile effort at compromise.
Unix should have been a player, but IBM joined the everyone-except-Sun alliance called OSF instead. It left a vacuum that Microsoft’s opportunistic marketing exploited. NT was a vapourware product, but Microsoft promised to help port it: creating MIPS, Alpha, even IBM/Motorola RISC chip PowerPC versions. NT promised to run 16bit OS/2 binaries and POSIX UNIX binaries. And Microsoft promised a unified API, "Win32", so code would run on DOS-based Windows and NT. By the time the warring Unix factions woke up to the threat and signed up to a common "Spec 1170" in 1993, nobody cared.
So the vapour platform allowed Microsoft to create a pincer movement. Microsoft told customers to wait for the 32bit version of Windows, Chicago, which would ship in 1993. This would be DOS-based but would offer many of the advantages of OS/2, such as long file names – and would run in 4MB. And they should start preparing for the Unix-killer, Windows NT. Not only was NT a Unix-killer, but it would morph into an all-singing, all-dancing object-oriented system called Cairo.
There were promises as far as the eye could see, right to the end of the Yellow Brick Road. IBM realised it had one last chance to regain the market, and recoup some of the billions of dollars it had spent on the OS/2 project. In Autumn 1994, a much-optimised OS/2 version 3.0 - Warp - was launched with heavy TV advertising, unusual for IBM. It came in two packs, one which included Windows, and one which took advantage of the Windows already installed on a hard disk. IBM was much smarter than Microsoft in realising the potential of the web: it was the first OS to include a web browser. Microsoft, meanwhile, was busily building an ambitious walled garden system, a "Compuserve-killer" to include in Chicago, and didn’t even include a TCP/IP stack in Windows.
OS/2 briefly caught the imagination of a small set of consumers, but it was far from being a turnkey consumer product - which it had to be, since the only major PC OEM who dared pre-install OS/2 was IBM’s own PC division. IBM’s support teams weren’t used to dealing with non-technical users. New OS/2 users were greeted with a laborious installation process, iffy device support, and a lack of native applications. OS/2 ran DOS and Windows so successfully, and had few compelling major applications of its own: so the big independent software vendors focused on the more lucrative Windows market.
As it turned out, Chicago didn’t ship until August 1995, and Windows 95 - as it was officially called - didn’t run in 4MB. NT was too big and slow for the market, and lacked office applications – the promise of portability of the Win32 didn’t really materialise. Windows NT didn’t take off until a year later, when customers demanded a version of the Windows 95 shell. By then, architectural changes removed much of NT’s USP. Microsoft had introduced arbitrary network connection limits on the workstation (which could until then function as a pretty robust departmental server) and moved graphics device drivers into kernel space, sacrificing stability for speed. Cairo was quietly abandoned.
Sponsored: DevOps and continuous delivery