Operating System Evolution: The Rest of the Story

From EDM2
Jump to: navigation, search

by Jeri Dube and Paul Giangarra

In our article 'Operating System Evolution' that appeared in Volume 7 of The Developer Connection News, we began a discussion of personal computer operating systems - from DOS, to Windows, to OS/2 - and how their evolution has occurred in parallel with computer hardware evolution. We saw how the weaknesses of each system drove the need to create the succeeding operating system. In this final article in the series, we'll look at Windows NT and the recent innovations by IBM 's operating system team with the microkernel-based version of OS/2.

Windows NT: Not Really New Technology

While IBM was developing the advanced versions of OS/2, Microsoft was working on their own 32-bit, desktop operating system - Windows NT. The NT in the name stands for 'new technology,' although except for a few advanced features, such as built-in security and unicode, NT contains no new technology. Furthermore, NT was initially marketed as a server system even though Microsoft then developed and announced a desktop version - NT's excessive memory and disk requirements caused Microsoft to change their strategy.

Microsoft structured Windows NT similarly to OS/2 - both systems run a large amount of code in kernel state; however, NT divides the kernel into parts. The lower layer of the 'kernel code' is known as the hardware abstraction layer (HAL). This layer masks differences in hardware systems from higher levels of the operating system. Most (but not all) hardware differences can be 'masked' in this layer. For example, the memory management hardware-specific functions are not abstracted in the HAL. This might optimize performance on specific hardware systems.

Above the HAL, the remainder of the kernel is structured in two parts: the NT kernel and the NT executive. The kernel deals with the most basic system operations, such as thread dispatching, multiprocessing synchronization, and hardware exception handling. The majority of classic kernel type code is in the executive. This is where the kernel extensions are defined for device support, file systems, and network support.

The NT 'undocumented' APIs allow you to get to the kernel functions from the user state. Microsoft used these APIs to build the 'operating system environment.' These are the subsystems in NT such as Win32, WOW on Win32, POSIX, and OS/2.

Runs Existing Applications: A Roll of the API

NT was the first implementation of Win32. With the introduction of new Win32 APIs and a new user interface in Windows 95, NT will only have a subset of the full Win32 API set. However, NT (according to Microsoft) will remain the only Microsoft platform in 1995 to implement the unicode, security, and multiprocessing capabilities of Win32. With the implementation of Win32 in NT, Microsoft also introduced a subset of Win32 called Win32s for Windows 3.1. IBM has enabled this subset in OS/2 Warp. The user interface for NT is the same as the Windows 3.1 interface. The mechanism for running Windows 3.1 16-bit applications on NT is called WOW (Windows on Windows). WOW maps the 16-bit APIs to the Win32 APIs but does not support many of the undocumented features, the VxDs, or the 16-bit graphics device interface (GDI) drivers. The result is that many Windows 3.1 applications might not be fully functional on NT. It was only with the release of Windows NT Version 3.5 that Microsoft finally enabled multiple WOW sessions that enable the separation of Windows 3.1 applications.

Nothing New or Innovative

Perhaps the most important point here is that Windows NT was not an innovative or evolutionary step in operating systems. It supported features and functions that have been in full operating systems for many years. Tasking, threads, 32-bit support, and security were not new to the desktop. The structure is classical and robust, but not necessarily enduring. These shortcomings pushed IBM to pursue a more revolutionary approach in its microkernel architecture.

A Microkernel-Based Operating System - A New Structure

As the pace of hardware evolution accelerates, the flexibility and adaptability of the software must increase. The industry trend (albeit slow) is to move toward a new way of structuring software so that it is componentized into modular, adaptable, reusable parts. This trend has led IBM to the next step in the evolution of operating systems - to incorporate interchangeable parts on a small, dynamic, and changeable base. OS/2 Warp Connect (PowerPC Edition) is the OS/2 Warp operating system implemented with IBM's Microkernel-based state-of-the-art architecture. This architecture will meet the requirements of the next evolutionary step of operating system software. In all previous versions of OS/2, even though the API set was portable, the kernel code was not readily so because of its size and scope. OS/2's structured, monolithic kernel included everything from user-level programming interfaces, to page table layouts, to page sizes, and policy on how to manage all parts of the system. IBM reduced the classic OS/2 kernel to a microkernel by removing all but the hardware abstractions. The effect of this hardware encapsulation is that the operating system itself, not just the APIs, becomes extremely portable.

What used to be a kernel in the OS/2 operating system is now split into three distinct pieces:

  • The first piece is the microkernel. The microkernel contains only the primitive functions necessary to abstract the hardware and support applications that exist on these abstractions. These primitive functions include memory management, tasking, I/O and interrupt processing, and interprocess communication.
  • The 'more than primitive' services that used to be available primarily as extensions to the kernel are now implemented as microkernel applications called Shared Services. Some of the services included in this category are networking, database management, and file system services. The IBM Microkernel acts as a server, with the Shared Services acting as the clients.
  • The final category, formerly the kernel services, is now operating system services. This category of services exposes the APIs and the semantics of the APIs to user applications. In this category, the clients of the operating system server are the applications. At the same time, the operating system services rely on the Shared Services for many of its services.

The Strengths of the Microkernel Architecture

Because the microkernel is easily changeable, it can quickly be adapted to new hardware systems. By encapsulating the hardware in the microkernel, nearly all changes that need to be made to the operating system to accommodate hardware are confined to the microkernel. This lessens the programming effort, as well as the testing effort, when the operating system is ported to new hardware.

The Shared Services are simply interchangeable parts that hook onto the dynamic, flexible base known as the microkernel. This structure makes the microkernel-based operating system modular. With this modularity come benefits that are indispensable to the new computing environment - scalability and extensibility.

The microkernel architecture is scalable enough to be used in imbedded processors, from palm tops to large parallel systems. The modularity of the system allows the size and anticipated use of the target hardware to determine what services need to be included in the operating system. For example, a microkernel imbedded in an automobile would not need a file system, whereas a large multiprocessor needs a high-performance file system.

The modularity of the system is critical to upgradability because new technology can be integrated alongside the currently running technology. The transition from one technology to the next becomes a well-controlled, repeatable process.

The microkernel-based system enhances the already-reliable base of a structured, monolithic kernel system by reducing the number of tasks and processes that have direct access to system resources. Because most tasks and processes run in application state outside of the kernel in the microkernel-based system, the system is less vulnerable to 'crashing.' This also adds to the upgradability of the system. For example, adding a new file system is no longer like adding a kernel extension but more like adding a new application to the system.

In addition to its other strengths, the microkernel architecture is well suited to run on multiprocessor and networked systems. The system is structured into tasks that can run as dispatchable units. Each of these units can run on a different processor in a multiprocessing machine or on different machines in a networked system. In the monolithic world, in order to dispatch tasks to different processors, the entire kernel would be mapped into each processor that was running a task. Furthermore, the underlying structure of the microkernel-based system is based on a client/server relationship. This structure is therefore well suited to run in a client/server environment.

Conclusion

Operating system evolution has been a natural process where the need to adapt to new elements in the computing environment has motivated the changes in operating systems. Charles Darwin said, '...from so simple a beginning endless forms most beautiful and most wonderful have been, and are being evolved.' Likewise, operating systems have followed this natural process. Each new operating system 'demonstrates a profitable deviation of structure, and gradations have existed, each good of its kind.'

Throughout the history of desktop operating systems, IBM has strived to maintain the good of earlier systems while making the necessary improvements to keep pace with the needs of the system users and exploiters. OS/2 Warp Connect (PowerPC Edition) might be the best example of maintaining the best from prior systems while adapting to the changes in the computing environment. OS/2 Warp Connect (PowerPC Edition) keeps the OS/2 operating environment and APIs intact and puts them on a new base - the IBM Microkernel.