Operating System Evolution

by Jeri Dube and Paul Giangarra

The computer industry has been evolving almost from its inception. As exciting as the first computers were for their time, it was obvious that they could be improved. Twenty years ago, when mainframes were behind glass windows and users sat in front of terminals with paper, the Central Processing Unit (CPU) and the operating system were involved in every interaction. When a user pressed a key, the electronic representation of it went from the terminal to the main computer to the operating system, and the response went all the way back to the terminal. This character-by-character interaction was an inefficient use of the CPU.

About 15 years ago the "cluster controller" was invented to offload the CPU, allow it to run more applications, and only deal with "important stuff". Keystrokes stopped at the controller, were echoed back to the terminals, and only when an "attention" event occurred was the CPU called upon for assistance. The operating system was responsible to find and dispatch the proper application for the attention, the application was responsible to request (if needed) all modified data since it was last signalled, and finally it could send (with the help of the operating system) a "chunk" of data back to the user/terminal. Then it waited for the next attention event. Computers were still behind glass; the main processors were more powerful; and the operating systems were multitasking, supporting virtual memory and many of the more powerful features of OS/2 today.

When the personal computer was invented a little over 10 years ago, the glass walls were broken down, the cluster controller was eliminated, and everyone got their own computer. Once again, keystrokes went all the way from the user's fingers to the CPU. DOS was the operating system and it could support one application at a time. Users, however, wanted more, and graphics capabilities began to be added to the hardware.

Evolution of desktop systems is a continuation of the overall evolution of computing. This article begins a discussion of the evolution of personal computer operating systems from DOS, to Windows, to OS/2. It looks at how the weaknesses of one system served as impetus to create the strengths of the next generation of systems. As Darwin said in On the Origin of Species, "...from so simple a beginning endless forms most beautiful and most wonderful have been, and are being evolved."

In the Beginning There Was DOS

DOS served as the catalyst software that created the personal computer (PC) industry. It yielded great influence on all future desktop operating systems. DOS standardized the FAT file system and provided an efficient, non-obtrusive platform that allowed the creation of a huge variety of applications. Because of that huge set of applications, no matter what new features and solutions an operating system might include, it must have enough of the DOS compatibility base in place to continue to support the DOS heritage of applications. DOS set a workable standard for PC applications that persists today.

The early versions of DOS were minimalist systems that provided the basics for what an operating system had to do. These basics consisted of three primary functions launching applications, managing files, and managing memory. Nearly everything that DOS did could be classified in one of these categories. For example, the DOS command language is actually just a DOS application, COMMAND.COM. Also, networking support in DOS is just a combination of applications with extensions to the DOS API set (that is, Terminate-and-Stay-Resident programs (TSRs) plus device driver support for networking devices).

As a minimalist system, DOS had its limitations. Many were hardware-based because DOS was designed to work on the Intel 8088 and 8086 processors and the off-the-shelf peripheral hardware from the early 1980s. The early PC design limited memory to 1MB, with only a 640KB partition for DOS and DOS applications. The Basic Input/Output System (BIOS) and device support code reserved the other 384KB of memory. Furthermore, DOS did not include support for specific graphic displays or printers; application developers had to provide such support in their applications.

Even more critical than the hardware limitations was the fact that DOS ran only one application at a time. This narrowed the productivity of the system and later constrained the exploitation of faster, more powerful hardware. In addition, DOS provided no protection scheme. Applications had full access to all system resources and system services. With many applications exploiting this free-for-all environment, an errant application often crashed the system and sometimes even corrupted valuable data by crashing the file system too.

Productivity applications needed to compensate for the weaknesses and limitations of DOS. For example, to fill the void in printer and graphic device support, productivity applications included drivers for a wide variety of devices. One of the key differentiators of a DOS application, such as a word processor, was the number of devices that it supported.

To overcome memory and protection limitations, system programmers developed DOS extenders. These extenders increased the amount of memory available to an application, allowed access to extended memory without expanded memory cards, or acted as virtual control programs that allowed more than one DOS application to run at a time. Although extended applications worked well individually, they did not work well together. Conflicts occurred when more than one program tried to use the processor's protected mode because the Intel 386 processor did not allow multiple protected-mode programs to coexist without explicit rules defined among the programs.

To overcome these conflicts, developers invented the DOS Protected Mode Interface (DPMI). DPMI defined the rules that let multiple DOS applications coexist in protect mode. DOS applications are DPMI clients that use the services provided by the DPMI host, such as interrupt management, page table sharing, and access to debug hardware.

Windows - The DOS Extender to Beat All Extenders

It is impossible to review the evolution of operating systems without including a discussion of Windows. Although Windows is only a DOS extender and not an operating system, it became important because it moved the boundary line between what is in a system and what is in an application. With the advent of Windows, display and printer support became part of the base system. Application developers could no longer use the number of printers and displays they supported to sell their products. The features of the application were forced to stand on their own merits.

Windows also eliminated some of the weaknesses inherent in the DOS operating system. Windows standardized graphical user interface (GUI) replaced the character mode interface and other homegrown graphical interfaces, and was a key factor in expanding the use of personal computers from mostly technical users to business and professional users.

Perhaps Windows' most notable enhancement to DOS was its support for application task switching. Task switching gives the impression of multitasking and allows users to start more than one task at a time and switch between them. In addition, Windows extended memory support beyond the 1MB limit to take advantage of the power of the Intel 286 microprocessor. Windows provided this function by serving as a DPMI host, parsing out memory beyond 1MB and allowing multiple DPMI clients to run simultaneously.

It is interesting to note that Windows 3.0 was the first product to serve as a DOS extender and as an extended application - it was both a DPMI client and a DPMI host. As a host, Windows provided access to greater than 1MB of memory and provided services to facilitate access to that memory. As a client, it provided a set of APIs that Windows applications used to take advantage of the host services. This DPMI client/host relationship in Windows provided the support for Windows 16-bit protected applications. However, Windows applications can also go around the client piece of Windows and have full access to DPMI. This is how Windows is able to support 32-bit applications.

Windows' Inherent Weaknesses

Although Windows provided the next evolutionary phase of operating environment support, it remained far from being a real operating system. There are some considerable weaknesses inherent in Windows because it is built on DOS. Although many DOS weaknesses are masked in Windows, they still exist and cause reliability problems. For instance, since all applications run together in a single address space, there is no separation between multiple running applications The result is no application security or crash protection. The DPMI facility could provide some protection but, since Windows was structured as a DOS extender without true multitasking and other basic operating system functions, Windows does not take advantage of this aspect of DPMI.

Although Windows gives the appearance of running more than one task or application at a time, it does not support tasking nor threading - it only performs cooperative switching. This means that an application continues to run until it explicitly relinquishes control back to Windows. Applications cannot be pre-empted by other applications because the concepts of priority and pre-emption do not exist between Windows applications.

Furthermore, Windows manages virtual memory in a somewhat clumsy and restrictive manner. Three factors share responsibility for this clumsiness:

• The Windows DPMI implementation
• The dependency on DOS
• The Windows design for Intel 286 and 386 class machines

As a result, Windows performs paging by either bypassing DOS and using a unique paging driver for different DASD adapters, or switching to real mode for each page I/O using DOS and/or BIOS.

Both these options have considerable disadvantages. In the first case, Windows burdens adapter providers by requiring a unique driver for each adapter. In the second case, the switching impacts system performance and burdens application programmers by imposing the preallocation of the paging file size (that is, predefining the maximum amount of virtual memory).

Another shortcoming of Windows is the defined mechanism to write a protect mode device driver Developers often use this mechanism, called a VxD, to add capabilities such as file management systems and networking support. The VxD allows these system extensions (a mutant form of 32-bit Windows 3.x applications) to run in protect mode and have privileged access to the hardware. However, for a DOS application to use a VxD, a programmer must modify the DOS application by at least inserting a stub. Furthermore, the Windows system extensions do not run on Windows NT - and may not be supported in Windows 95.

OS/2 - The Best of DOS, Windows, and More

Unlike most evolutions, the operating system evolution did not occur in chronological order. (See Figure 1.) Although OS/2, from its very beginnings, was more technologically advanced than Windows 3.0, IBM and Microsoft produced OS/2 before Windows 3.0 was developed and became commercially successful OS/2 was the first true, high-volume operating system for Intel processors that provided basic operating system primitives. The primitives - semaphores, virtual memory, threading, multitasking, and full file system support - created the foundation for an operating system that was robust, efficient, secure, and reliable.

IBM realized from the commercial success of Windows 3.0 and 3.1 that it needed to take the best from Windows (for example, a standardized GUI) and also overcome its shortcomings. From the very beginning, OS/2 addressed the task of providing true (desktop) operating system robustness - OS/2 supports multiple "tasks" running protected from each other (Crash Protection) and defines a set of standard, durable interfaces for adding file systems, device support, networking support, and other operating system extensions to the kernel. In addition, the system had to support the vast array of DOS and Windows applications and provide a path to 32-bit exploitation.

OS/2 - Evolution Within Itself

OS/2 completed the first step of overcoming Windows' shortcomings by providing operating system robustness in OS/2 1.x. However, because it was implemented to run on Intel 286 processors, this true operating system had a few shortcomings of its own:

• It supported segment swapping, instead of true VM paging
• It ran under 16-bit protect mode
• It ran DOS applications in real mode

Although the first version of OS/2 let multiple application tasks run protected from each other with true multithreading, OS/2 1.x did not exploit the 32-bit capabilities of the Intel 386 hardware. Consequently, OS/2 1.x performance was not optimal and memory swapping in 16-byte to 64KB chunks was clumsy.

OS/2 2.x overcame these shortcomings by fully exploiting the Intel 386/486 hardware OS/2 developers replaced the clumsy segment swapping with full virtual memory management paging support OS/2 2.x's 32-bit memory model allows applications to deal with memory objects as large as 4GB Furthermore, the OS/2 2.x developers improved the exception processing and error handling, and tuned OS/2 for optimal performance/minimal storage.

Perhaps the most noticeable change in OS/2 2.x was the exploitation of the Intel 386 Virtual 86 (V86) mode support. This resulted in OS/2's Multiple Virtual DOS Machines (MVDM) support, which runs multiple concurrent DOS applications significantly better than any other operating system IBM used a full, robust multitasking implementation of DPMI on top of the MVDM support to run Windows. This implementation used the actual Windows kernel rather than an emulated version of the kernel, allowing Windows applications to run with full compatibility using Windows 3.1.

OS/2 earned the loyalty of many end users who appreciated the Crash Protection and flexibility of multitasking by optimizing the DOS and Windows application performance running on MVDM For application developers, OS/2 2.x introduced the 32-bit application programming interfaces (APIs). To satisfy the application developers needs, the OS/2 development team ensured that the APIs were scalable, durable, extendible, and portable.

• Scalability is proven by OS/2 Warp, which runs on a 4MB client system, and OS/2 SMP, which runs on a 16-way symmetric multiprocessor.
• Durability is proven because the same 16-bit APIs in OS/2 1.0 are available today No changes to the 32-bit APIs were necessary from OS/2 2.0, 2.1, 2.11, to OS/2 Warp.
• Extendibility is proven as new APIs have been added to enhance the functions of OS/2
• Portability is proven through the successful port of OS/2 and pure 32-bit OS/2 applications to the PowerPC, using the 32-bit APIs.

Summary

The evolution of hardware and the operating systems to support it has been an amazing story, going back well before the PC We have discussed how DOS, Windows, and OS/2 evolved to keep up with the evolving computer industry. In a future article, Windows NT and IBM's microkernel-based operating systems will be discussed.

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation