In October 1991, IBM released OS/2 2.0 “Limited Availability” (or LA) at the Fall Comdex in Las Vegas. This was a semi-official release of 32-bit OS/2, effectively a beta version, although it wasn’t called a beta. At the same Comdex, IBM also announced that the planned release date of OS/2 2.0 was April 1992, a few months later than the previously expected 1991 release. However, IBM had promised 32-bit OS/2 by the end of 1991 to certain corporate customers, and OS/2 2.0 LA was a fulfillment of that promise.
It is useful to note that October 1991 also was when Microsoft made available the first limited developer release of Windows NT, but the final public release of Windows NT 3.1 was still about 20 months away. At the Fall Comdex, Microsoft talked about releasing NT in the second half of 1992, but that turned out to be wildly unrealistic.
OS/2 2.0 LA was the first semi-public release of 32-bit OS/2, and the first major 32-bit PC operating system. Several variants of 32-bit UNIX had been already available (starting with XENIX in 1987), but none of those had any hope of becoming a successor to DOS, and most never even tried.
OS/2 2.0 LA supported 32-bit flat model applications, paged virtual memory, and virtual DOS machines (VDMs). In addition, the release sported a brand new desktop, the object-oriented Workplace Shell. While the other features had been already present to some extent in other PC operating systems, the Workplace Shell was new.
Another new feature was the Boot Manager, which allowed users to install and boot multiple operating systems. Dual boot support for OS/2 existed previously, but required OS/2 to share a primary FAT partition with DOS. The Boot Manager allowed OS/2 to be installed on an extended partition, formatted as either FAT or HPFS. Unlike the earlier dual booting solutions, the Boot Manager was essentially OS agnostic.
Many technologies were brought over from OS/2 1.x, such as the ATM font manager (PostScript fonts) or the REXX scripting language. REXX was now a standard component of OS/2, which greatly aided its wider adoption.
There was no built-in networking support, although networking was available with LAN Server and other products. There was no multimedia support yet, but that was something only just appearing on Windows.
IBM’s strategy for OS/2 was to become “better DOS than DOS” and even “better Windows than Windows”. For DOS, there was little question that this was true. For Windows, Microsoft did its damnedest to ensure that IBM would not succeed. In addition, OS/2 2.0 of course supported existing 16-bit applications written for OS/2 1.x.
After Microsoft quit OS/2 development, IBM was left in a difficult position with regard to supporting non-IBM systems. OS/2 2.0 LA clearly demonstrated that. The operating system could be installed on a vanilla AT-compatible 386 or 486 system, but there were no drivers for storage controllers other than ATA, and no graphics drivers beyond VGA and perhaps IBM-compatible 8514/A or XGA cards (not typical in non-IBM systems). The disk drivers shipped with OS/2 2.0 LA were quite similar to the ones shipped with OS/2 1.3 (DISK01.SYS and DISK02.SYS), rather than the more modular storage drivers shipped with the final OS/2 2.0 release (IBM1S506.ADD, IBM1FLPY.ADD, OS2DASD.DMD, etc.).
On the other hand, IBM’s own PS/2 systems were well supported, including XGA and SCSI disks and CD-ROMs. Printer support, a perennial weak spot of OS/2 1.x, was much improved, and the LA release already included a broad palette of printer drivers.
Unlike Windows (including NT), OS/2 never required DOS to be installed and was supplied on bootable floppy disks. The OS/2 installer was significantly reworked for version 2.0; the first text-based installation phase was similar to the old OS/2 1.x installer, but now only handled disk preparation. FDISK could now be run interactively and allowed the user full control over disk partitioning, including Boot Manager installation.
The second phase of the installer was fully GUI-based, with a minimal Presentation Manager installation limited to VGA support.
The installer provided a good degree of control and was easy to use. It was close to the finished product with no obvious rough edges. The contrast with the Oct ’91 preview of Windows NT was especially striking.
There was a somewhat unexpected commonality between IBM’s OS/2 2.0 LA and Microsoft’s Windows NT preview from October 1991: Both were built using the Microsoft C 386 compiler. Microsoft first developed a 386 C compiler around 1986 and used it to build the 32-bit version of XENIX. When the work started on 32-bit OS/2 2.0 in late 1988 or early 1989, the C 386 compiler was a logical choice. And the same compiler was also a logical choice for the NT team when work started on the Intel version of NT. The 32-bit compiler was not available as a product (except in the XENIX development kit, where it could be only used to create XENIX executables) until 1993 as Microsoft Visual C++ 32-bit Edition.
When IBM took over the development of OS/2 2.0 from Microsoft, IBM did not have a 32-bit x86 compiler. The IBM Toronto Lab was tasked with the development of one, later released as IBM CSet/2. However, OS/2 2.0 was still built with the older Microsoft compiler. The evidence is in the strings embedded in executables: “MS Run-Time Library – Copyright (c) 1990, Microsoft Corp”.
IBM had the rights to the Microsoft C 386 compiler and kept using it for building certain OS/2 components until the end; the compiler was shipped with the OS/2 DDK.
DOS and Windows
The DOS session support in OS/2 2.0 LA was fairly complete and mature, with no major differences from the final release. IBM emphasized DOS support and OS/2 2.0 was very good at running DOS applications, a huge improvement over OS/2 1.x. DOS sessions could be switched between windowed and full-screen at will, and there was a multitude of settings specific to DOS sessions.
DOS sessions in OS/2 benefited from a large amount of free conventional memory and a crashing DOS application did not affect OS/2, both well known weaknesses of the OS/2 1.x DOS support. It was even possible to boot a user-supplied DOS version from a floppy or a floppy image, and many DOS character device drivers could be loaded in DOS sessions.
The Windows support, on the other hand, was not yet finished. OS/2 2.0 LA came with a stripped version of Windows 3.0a, slightly modified and rebuilt by IBM. Only the core Windows utilities were shipped, perhaps to save disk space. Windows was only supported in standard mode and only in full-screen sessions, but with clipboard and DDE support.
Unfortunately for IBM, delaying the final release of OS/2 2.0 gave Microsoft enough time to release Windows 3.1. Because OS/2 2.0 GA only came with Windows 3.0, it was immediately obsolete.
Compared to the Oct ’91 preview of Windows NT, OS/2 2.0 LA was far, far ahead in this regard. The October preview of NT provided no support for DOS or 16-bit Windows applications whatsoever.
Installing OS/2 2.0 LA in a VM was not entirely trivial. Some hypervisors (e.g. VMware) have a hard time with 32-bit OS/2 in general, while others (Virtual PC) support 32-bit OS/2 but fail to start the OS/2 2.0 LA installer. The symptom is a black screen with an error message about missing COUNTRY.SYS.
The culprit is the disk driver (DISK01.SYS) in OS/2 2.0 LA. As noted earlier, it’s quite different from the GA version, but also different from OS/2 1.3. Based on a quick analysis, the driver is probably unintentionally using a uninitialized variable when it first tries to operate the floppy drive. This does not cause problems on real floppy controllers, but many hypervisors do not handle the unusual request correctly. Slightly modifying the floppy controller emulation for VirtualBox took care of the problem.
There is another problem, which only appears intermittently. The OS/2 loader contains poorly written timing-related code which can trigger a division by zero on faster systems and the system is hung. The symptom is a black screen (usually) and lack of progress when booting the installation disk. This is a bug in OS/2 and affects physical systems as well. Rebooting the VM a few times usually gets past the hang.