OS/2 Warp Review

From EDM2
Jump to: navigation, search

by Howard Gilbert

OS/2 Warp

IBM and Microsoft began joint development of OS/2 in 1985. It was not based on a radical new design that broke any new ground. The idea of a protected kernel controlling insulated application programs had been around for twenty years. Storage management was based on the 286 CPU chip architecture, which in turn borrowed heavily from early DEC minicomputers. The requirements of the Graphic User Interface were understood from the Macintosh and Windows 1.0 systems.

Originally, OS/2 was expected to gradually replace DOS and Windows. It provided, after all, a real operating system. Application programs could not interfere with themselves or with each other. The system could natively use larger amounts of memory. Yet the system maintained the command language and file structure of DOS.

Unfortunately, the April 15, 1987 announcement of OS/2 was accompanied by the first generation of PS/2 Microchannel computers. IBM made sure that OS/2 was supported only on its own machines, while marching down a technological dead-end, surrendering market share to clones. OS/2 required more memory, at a time when RAM prices were high. The decision to use 286 memory management meant that OS/2 could not run DOS programs well.

In the summer of 1990, Microsoft announced Windows 3.0 and it became a monster hit. The relationship between IBM and Microsoft was already strained, and further development of OS/2 was left entirely to IBM. Microsoft went on to develop NT, enhance Windows, and produce Windows 95.

Eventually, IBM figured out what was wrong and fixed it. OS/2 2.0 and 2.1 used 386 memory management, ran almost all DOS programs, and ran most Windows applications as well. IBM now supports clone computers, and has largely abandoned its PS/2 Microchannel family for the same PCI, ISA, IDE, SVGA architecture everyone else uses.

In the fall of 1994, IBM released Warp (OS/2 3.0) and made its last big marketing push for OS/2. IBM had a product out ten months before Windows 95 would be released. OS/2 was technically a better system than Windows 95 would be, with real program integrity, priorities, and server-quality I/O. None of this was discussed in any of the IBM ads or announcements. Instead, IBM concentrated on a "one button connection to the Internet" through IBM's expensive public network. It would be six months before IBM released a version of Warp for corporate and campus use (with LAN support) and IBM never succeeded in capturing market share for Warp among home computer users.

As it became clear that Warp was not going to take off, and as the Windows 95 announcement came closer, IBM all but abandoned support for OS/2. The whole marketing arm and support team was disbanded. Versions of OS/2 shipped pre-installed on IBM PCs did not support the video or disk hardware provided. Third party software suppliers were ignored and lost interest.

The recent release of OS/2 Warp 4.0 (Merlin) finally makes good on IBM's promise to support and update the product. It provides a few more years of life for corporate customers who installed large numbers of OS/2 machines as their internal standard. However, some of OS/2's strongest supporters believe that Merlin is probably the last chapter in the history of this operating system.

OS/2 today reflects a steady evolution and refinement of a system design that is almost a decade old. The system reflects the strategy, "If it ain't broke, don't fix it." OS/2 device drivers are 16-bit programs written, in many cases, back in the days when Microsoft was doing much of the development work. Older drivers still work, so IBM has felt no urgency to replace them.

OS/2 accommodates Windows programs by including a complete copy of Windows 3.1. Again following the line of least resistance, some of the Windows components are given system privileges and run as part of the OS/2 operating system itself. It is possible to boot a copy of DOS inside OS/2, but OS/2 itself does not run on top of DOS or use BIOS services (except as a last resort when there is no native OS/2 driver for a disk device).

Native OS/2 Programs

Each OS/2 program runs in its own address space. It is common to talk about the old 16-bit programs and the newer 32-bit programs, but OS/2 does not separate the two or treat them differently. More accurately, OS/2 assumes that each of its applications may have a mixture of 16-bit and 32-bit pieces. OS/2 is itself a hybrid system with mixtures of both types of code.

In contrast, a Windows program is either written to use all WIN16 services or all WIN32. On NT, the WIN32 programs all run in their own address space, while WIN16 programs by default run together in a special virtual machine. Even in Chicago, where the operating system itself is a mixture of 16-bit and 32- bit components, applications are segregated into WIN16 or WIN32.

OS/2 recognizes when a program has been constructed using the old 16-bit tools (producing variable sized segments) or with the new 32-bit tools (providing 4K pages). The different EXE file structure changes the way that the program is loaded into memory. Once they start running, however, all modules get the same services and all are assumed to have both 16 and 32-bit components.

Native OS/2 programs open files, request storage, or load programs by calling standard system routines. These routines are packaged in the same sort of Dynamic Link Libraries (DLLs) that are used in Windows. There are 16-bit and 32-bit libraries with versions of all the standard system services, and a program can choose which to call.


Unlike DOS and Windows, an OS/2 program does not run in privileged mode. It cannot access hardware devices and cannot alter the control functions of the CPU chip or mainboard. Privileged operations are restricted to the operating system kernel and the device drivers. Instead of calling the kernel directly, application programs call routines in the interface DLL, and those routines pass the request on to the kernel.

There are four ways to build new program support into OS/2.

  1. Very simple services can be provided as routines in a DLL module. They will operate as extensions of the application program that calls them and will have access only to the storage of the calling program.
  2. If the subroutines in a DLL module need to share data between programs, they can allocate an area of shared storage. This represents a slight exposure, since a malicious program could damage the shared control blocks.
  3. Massive components, such as the Communications Manager that connects to mainframes or the DB/2 database product, can include EXE modules that must be started and run as programs in the background. User applications can communicate to such programs using shared memory or named pipes.
  4. The supervisory services of the OS/2 kernel can be extended by adding new device drivers. Although it is normally expected that a device driver will drive devices, there are several examples of device drivers that gather information about storage use or provide debugging support for C programs.

An OS/2 application program runs isolated within its own address space. It cannot directly access the 128K hardware address areas in the first physical megabyte. It cannot directly manage the I/O devices on the mainboard or bus. All services are defined by routines that reside in DLLs. This produces a degree of portability.

By filtering all user requests through the DLLs, OS/2 isolates the application environment from the underlying implementation of the operating system. Clearly the old 16-bit programs benefit from this design, because they do not have to be updated when the system changed. This has also been used to achieve portability.

In the near future, IBM will release its version of the PowerPC and a version of the OS/2 Operating system designed for it. This is a microkernel system that could support Unix programs as well. The OS/2 component will supply a full set of the 32-bit DLLs with the same set of routines as the current Warp program support. Programs written to run as 32-bit native OS/2 programs will be able to run on the PowerPC simply by recompiling them for the new CPU chip.

DOS Virtual Machines

In Windows 3.x, Windows NT, and Chicago, Microsoft uses the virtual machine feature of the 386/486/Pentium CPU to isolate and control badly behaved DOS programs. The application program sees a one megabyte address space with 640K of user area. The program can use any of this storage and can call any DOS or BIOS service.

OS/2 takes the concept of "virtual machine" much more literally. It does not simulate the DOS services for a device, it simulates the device itself. While Microsoft creates a virtual machine that will fool an application program, IBM creates one that can fool an entire operating system. It is possible to load an ordinary copy of DOS 4 or 5 into the virtual machine just as one would boot DOS into a real PC. It is also possible to load other x86 operating systems, like the Novell DR DOS product.

Of course it is not necessary to install a copy of one of the old operating systems. OS/2 comes with a stripped down version of the DOS routines that provide enough function to run DOS application programs.


To enable general purpose virtual machines, OS/2 supports Virtual Device Drivers (VDDs). A VDD is a program loaded from CONFIG.SYS to extend DOS support within the OS/2 system. The VDD is called whenever a new virtual machine is created. The VDD can then create some new type of virtual device. OS/2 supplies VDDs that simulate most of the standard PC devices (the keyboard, mouse, VGA, COM port, printer port, and all the anonymous timer and controller chips on the mainboard). Additional VDDs are needed only to support unusual devices.

Consider the IBM WindSurfer Card. It contains a Digital Signal Processor (DSP) chip connected to an external microphone and speakers (as a sound card) and to an external phone and phone line (as a modem). It can function as a 14.4Kb modem, as a normal multimedia sound card, or the sound card component can be connected to the phone line to provide an answering machine, speaker phone, and call management system. There is support for the card in both Windows and OS/2. However, to run the Windows programs under OS/2, IBM has to supply a VDD. It creates a virtual DSP chip for the virtual machine. The Windows support can then "program" the virtual DSP as they would a real chip. The VDD checks to see if the real chip is busy (with programs from the OS/2) environment before passing on commands from the Windows environment.

A VDD can either pass raw hardware commands on to the real device, or it can simulate the behaviour of the real device and "do the right thing" whatever that means. In "fullscreen" mode, a DOS program is given the opportunity to reprogram the real display adapter. It can change resolution, redefine the colours, or load fonts. Before OS/2 switches to another program, it dumps all the programming from the adapter into memory. When it switches back, it reloads the screen setup.

DOS programs can also run in a window on the OS/2 desktop. OS/2 presents the program with a virtual VGA. Any change that the program requests to the VGA "screen" are converted into a command to make the corresponding change within the window. The user sees the same result, although the underlying programming to the display adapter has been extensively processed.

The VDD interface is not constrained to simulate a real piece of hardware. It can provide a general method of extending OS/2 services and subsystems to the DOS or Windows environment. Various LAN communication packages provide VDDs that extend NETBIOS, SNA, Novell IPX, TCP/IP, and LAN Requester functions to DOS programs.

Although the name and original intent of the VDD were to provide device emulation, structurally a VDD is an authorized part of the OS/2 operating system to which DOS programs can directly communicate. The VDD can receive a request including parameters and data. It can then execute the request within the OS/2 kernel, or it can pass the request along to OS/2 subsystems.

An important case of the Service VDD strategy is support of file I/O. Each DOS virtual machine is given simulated hardware level access to the disk drive, but in read-only mode. Write access at the hardware level from DOS programs would bypass file locking and would corrupt the directory structure.

For DOS programs to gain normal access to disk files, they must send the request through the file system support in the OS/2 kernel. The application programs still makes a standard DOS call (INT 21) for file I/O. However, this request is trapped by the dummy OS/2 version of the DOS operating system. If a real copy of DOS 4, DOS 5, DOS 6, or DR-DOS is booted into the virtual machine, OS/2 provides a device driver named FSFILTER.SYS that should be added to the CONFIG.SYS of the DOS system. In either case, application requests to open, close, read, or write files are trapped and sent through the VDD interface to the OS/2 kernel. Incidentally, this also provides DOS programs with access to special devices (CD-ROM, floptical) and network server volumes without requiring that a driver be added to the DOS environment. DOS inherits any device or network support actually installed in the external OS/2 system.

There is a sort of "passthrough" generic VDD built into OS/2. If a DOS or Windows program starts to do I/O to an unknown device for which no OS/2 support has been installed, and if the DOS programs installs an interrupt handler for an IRQ that no OS/2 device driver has claimed, then OS/2 will configure the system so that all the DOS I/O operations are passed on to the real hardware, and all the device interrupts are passed on to DOS. The program will run somewhat slower than under real DOS, because the OS/2 support adds administrative overhead to each operation. But this trick can be used to support an odd type of CD-ROM device, a Localtalk communications card, or any other hardware that has only DOS drivers.

Windows Sessions

To run a Windows program, OS/2 creates a Virtual Machine, boots its stub version of DOS into the machine, then loads a slightly modified version of Windows 3.1 named WINOS2. Modifications are needed so that Windows will allow a VDD to control the storage management tables on the CPU chip and so that Windows will share use of the screen with the OS/2 desktop.

When the OS/2 for Windows package is installed, it updates a half dozen key DLL routines in the C:\WINDOWS directory, but leaves most of the installed Windows 3.x system unchanged. The same Windows directory will then run under either DOS or OS/2. The standalone version of OS/2 contains its own copy of the Windows 3.x modules and programs and installs them in the \OS2\MDOS\WINOS2 subdirectory. The modified version of Windows runs differently under OS/2 than under DOS. In common jargon, the term "WINOS2" is used to refer to Windows operating in its OS/2 mode.

WINOS2 installs a standard set of core modules (USER, GDI, KRNL, *.DRV) and IBM has tracked the changes that Microsoft made within the Windows 3.x release. Currently support is available to install OS/2 on top of Windows 3.1, Windows 3.11, WFWG 3.1, or WFWG 3.11. However, in order to install in Windows for Workgroups, WINOS2 must disable the loading of the network related VxD components.

Both OS/2 and Chicago share the problem of making sense of SYSTEM.INI when they upgrade an older Windows 3.x system. The installation program will certainly recognize all the standard Windows stuff, and it may also recognize a few of the more popular options. However, drivers for exotic devices (such as the WindSurfer card) or more unusual options may not be understood. If WINOS2 does not start correctly after the OS/2 upgrade, it may be necessary to try to start it "fullscreen", examine the error messages, and then manually edit SYSTEM.INI to remove unsupported options.


One of the more confusing elements of OS/2 is the System Object Model (SOM) and its relationship to the Workplace Shell (WPS). Normally this area is regarded as a deep matter of interest to the techies. Unfortunately, all of IBM's other strategic initiatives (SAA, AD/Cycle-Repository, OfficeVapor) have fizzled out. If IBM has any strategy left, it appears to be "Workplace" and SOM is the underlying technology. If this initiative dies as well, then Microsoft advances unopposed.

All Windows services are provided by DLL routines. When an application program is built, it is bound by name to particular routines in particular DLL modules. A program that "surfs the Internet" would use routines in the WINSOCK.DLL library. If there are several versions of the library installed on the machine, Windows will find the DLL in the current directory of the first application to reference the library, or if one is not there then it will use the one that comes first in the PATH. Later on, all Internet programs will share the same WINSOCK.DLL that was first loaded.

However, a program written to use the WINSOCK routines will work only on the Internet. It will not use other types of networks such as SNA. For thirty years, operating systems have provided a more general model for servicing at least I/O requests. A generic interface is designed. When an application program uses it, the system dynamically decides which type of support to use and connects the appropriate routines. Today, most of the PC operating systems can accept the file name "\\OURSERVER\PROJECTS\PAYROLL" and will dynamically connect it to a Novell, IBM, Microsoft, or DEC file server using NETBEUI, TCP/IP, or IPX.

The ability to dynamically select the appropriate support routines is typically limited to the operating system. For example, in Windows Microsoft has defined ODBC, a generic interface to databases. It is supported by an ODCB manager that handles installable ODBC drivers supplied by the database vendors. When the client programs makes a request, the ODBC manager selects the appropriate vendor supplied DLL routine based on the type of database to which the request has been directed.

In its Workplace strategy, IBM generalizes this type of linkage and extends it to many parts of the operating system and the user interface. Instead of just supporting directories on network servers, or SQL database vendors, IBM supplements the DLL structure with a language-independent, system-independent object-oriented technology called SOM that allows generic operations to be routed to dynamically selected, application supplied routines.

SOM allows programs and products to dynamically extend the definition of certain type of generic system objects. The operating system begins by defining documents, programs, printers, servers, folders, controls, devices, and other stuff. The products can then refine these rough definitions with derived categories. For example, some types of database queries will return something that looks and acts like a datafile or spreadsheet (a document-like object). Others may return a collection of items that looks and acts more like a directory filled with results (a folder-like object). If the actions (double-clicking, dragging, dropping, discarding) and the results follow the same behaviour as the built-in system objects, then the user interface is simplified.

Sometimes when you describe an abstract concept, the picture is so vague that it doesn't make sense. A second opinion covers the same ground in concrete terms. After OS/2 has loaded all of its device drivers, the SHELL= statement in CONFIG.SYS tells it what program to load to create the user interface. CSHELL is distributed by IBM as a character mode shell that uses no GUI features. It uses the least memory and is a reasonable choice for dedicated servers with limited user input. MSHELL initializes the Presentation Manager to enable Windows on the screen, and it presents a kind of Program Manager. It takes a bit more room, but allows GUI applications. CSHELL and MSHELL are special add-on options for restricted environments. Normal behaviour is to load PMSHELL and get the standard Workplace desktop screen. PMSHELL triggers both Presentation Manager and WPS.

Presentation Manager has two parts. An OS/2 process runs under a special full screen session. When it receives control it initializes the screen in graphics mode with particular hardware parameters (resolution, refresh rate, number of colours). When that session is active (displayed on the screen) PM controls output to the screen and input from the mouse and keyboard. The other part of PM is a set of DLL routines that provide application programs with GUI elements (windows, menus, fonts, controls).

The Workplace Shell (WPS) is a system component that uses PM services. Just as a Word Processor uses PM to create a window with a title bar, menu, and input area, so WPS uses PM to fill the background of the screen with icons, to create windows filled with icons or trees of icons, to display a popup menu when an icon is selected and the user presses the right mouse button, and to display a notebook when the user selects "Open Settings" for a icon.

When PMSHELL is loaded, it examines the contents of the \OS2\OS2.INI database and the extended attributes of the \DESKTOP directory tree. It uses this information to create the WPS objects that appear as icons on the screen. It then calls PM services to display the icon that represents each such object.

There are three kinds of WPS objects.

  1. Objects that represent files and folders (directories) are simply the visual representation of the disk file structure. When a disk directory is shared on the network, others who access the same directory see the same arrangement of icons, because information about the objects is recorded in the disk directory.
  2. Objects that represent application programs, templates, and most of the system controls are saved as entries in the OS2.INI database. Although such objects may appear to be "in a folder", they are not part of the directory structure on disk. Such objects cannot be shared, either through the network or by alternate versions of OS/2 booted on the same machine. If OS2.INI is lost, they must be recreated.
  3. Other objects can be created temporarily to present a graphical representation of some other process. For example, a WPS printer appears to "contain" documents that actually represent the jobs in the print queue. As old jobs finish up, they disappear. New jobs arrive and are display as new icons. Such objects are not saved, because the current contents can be determined at any time by calling the system spooler for a list of jobs pending in any queue.

Without SOM, the Workplace Shell would simply be a user interface created by IBM to display a specific set of controls and functions. It would, essentially, be like the Windows Program Manager or File Manager. However, as new products are installed into the system, they can extend the function of the WPS.

A product can create a new type of WPS object (or a new version of an existing object) by calling SOM to create new object classes derived from the original WPS object categories. The program must supply the name of a DLL module that supplies the new or modified operations associated with objects of the class. The IBM TCP/IP for OS/2 product, for example, creates new object categories for Telnet sessions (terminal logon to other computers) and FTP sessions (file transfer to or from an Internet server). The Multimedia Viewer distributed in the Bonus Pak with Warp creates a new type of folder called a Light Table in which image files are represented by a reduced view of the image rather than an abstract document icon.

The DLL routines that implement the object are called by PMSHELL to draw the icon (or whatever) on the screen, to open the object, to display menus, and to drag, drop, and delete the object. If an operation will take a long period of time, the DLL routine can use the multithreading capability of OS/2 to create a task running independently in the background. This prevents the "hourglass" icon from appearing to hold up the user interface. For example, when WPS drag and drop are used to copy, move, or delete a large folder of files, the actual file copy occurs under a thread created for the purpose. The thread runs under the PMSHELL process.

Programs can have errors. If there is a bug in a DLL routine used by PMSHELL, it is likely to crash the entire WPS. All the icons and folders disappear (though the applications continue to run). Shortly the desktop is redrawn with a new set of icons. This underscores a functional restriction of the WPS/SOM design. SOM allows applications or products to extend the WPS function, but for performance reasons it is not possible to isolate the extensions from the standard IBM WPS components. Bugs in the extensions appear as a WPS failure. Fortunately, WPS can easily restart itself.

Though SOM is itself object-oriented, it can be used by programs written in any language. In OS/2, the simplest interface to SOM technology is through VX-REXX, a WATCOM library and language development environment for the standard OS/2 REXX language. The most expensive interface to SOM is the VisualAge product family. Since SOM is primarily oriented to the end-user interface, it is supported under OS/2, AIX, and on the PowerPC.


OS/2 is a hybrid system containing internal components that run in both 16-bit and 32-bit modes. Applications can run in either mode. Requests are translated between 16 and 32 bit forms as needed.

A native OS/2 program runs without privileges in its own address space. It requests services by calling routines supplied in DLL modules. System and I/O requests are passed to the kernel and device drivers, while database and communication requests are often passed through a "pipe" to other programs running in the background.

A program written to run in the 32-bit mode of OS/2 will be portable to the PowerPC, where the operating system will supply a set of DLLs that duplicate OS/2 services. Even so, there are relatively few programs written as native OS/2 applications.

A DOS or Windows program runs under OS/2 in a virtual machine. It requests services by making standard DOS or BIOS calls or by directly manipulating virtual devices. The set of virtual devices can be extended by loading VDD modules during OS/2 initialization. Some OS/2 VDDs mediate between many users and a shared display, sound card, or print spool. Some acquire exclusive use of a device and pass through all the DOS operations to the real hardware. Some VDDs emulate no real hardware, but provide a conduit for DOS program requests to more complex database, communication, or file services supplied by the external OS/2 system.