OS/2 was initially designed to extend the capabilities of DOS by IBM and Microsoft Corporations.
There were several limitations in DOS in the areas of Memory Management, Multitasking, System Extendibility, and Graphical User Interfaces. This joint venture took place in 1985. Under the agreement, both companies would jointly design, develop, and own the resulting product.
The reason to such a joint venture was to design a single advanced operating system that would be exploit the capabilities of DOS and to create a single industry-standard operating system that was endorsed by the two leading companies in the PC market.
IBM, which is a traditional hardware company during those days, wrote most of the software marketed for its larger systems. Whereas, Microsoft was a leading Independent Software Vendor that developed the DOS, Windows and a variety of other tools.
This joint venture was a multisite development, wherein the design, development, and testing of OS/2 was done by physically distant partners. The time frame for the development of OS/2 was from 1985 to 1987. During this time the OS/2 assumed many different names such as DOS5, DOS 286, and CP/DOS.
Initially the OS/2 was developed from the MT-DOS and DOS 3.2 source code bases and did not include the Presentation Manager (PM) GUI. But in the later versions of OS/2, the Presentation Manager was an integrated part of the Operating System.
OS/2 was originally supposed to run on both 8088 and 80286 systems, but later it was simplified to work with 80X86 architecture because memory-management requirements for supporting both the processors were not feasible.
2. REQUIREMENTS FOR DEVELOPMENT OS/2
The major requirements for the development for OS/2 are :
Break the 640KB physical memory barrier and support up to 16MB of physical memory
Make use of Virtual Memory to extend the Physical Memory resource of a system
To provide a protected Multitasking environment
Provide an extendible, flexible system Application Program Interface (API)
Provide a Graphical User Interface (GUI)
Support DOS application binary compatibility to encourage migration from DOS to OS/2
The OS/2 system is composed of the kernel, device drivers, dynamic link libraries, and applications programs. The structure of OS/2 is illustrated in the Figure 1. The kernel is the heart of the operating system, which contains the control program that runs with supervisor privileges. As in DOS, the kernel uses device drivers to access the system’s hardware resources. The most critical portions of the operating system, such as multitasking, memory management, interprocess communication, DOS compatibility, and I/O reside in the kernel. Many of the system’s API is located in the kernel, but some of them are located in the dynamic link libraries – shared libraries that can be used to extend the functionality of the system.
The OS/2 multitasking architecture provides the capability to execute programs concurrently in a protected environment. The model consists of a hierarchy of multitasking objects called sessions, processes, and threads. The session is at the top of the hierarchy, and the thread is at the bottom. The session is the unit of user I/O device sharing. Processes are analogous to programs, and are the unit of sharing for resources such as memory, files, semaphores, queues, and threads. A thread is the basic unit of execution, and a single process may have multiple threads that execute concurrently within it.
Each session consists of a logical video buffer, logical keyboard, logical mouse, and one or more processes that are said to be running in or attached to the session. The logical devices are per-session representation of the actual devices. Processes running in the session perform their user I/O on the session’s logical devices. Only one session at a time has its logical devices mapped to the actual devices, which is called the foreground session, whereas the other sessions are in the background. Users can change the current foreground session by issuing commands to switch between sessions with the keyboard or mouse. Sessions are used to provide an infrastructure for program management and use I/O device sharing.
A process is the basic unit of resource management in OS/2. A process is created by the invocation of a particular program. Programs are invoked by the issuance of a DosExecPgm system call with the name of an executable program file as the parameter. Each process has its own memory, threads, file system, and interprocess communication (IPC) data structures. A thread is a unit of processor dispatching and each thread has its own scheduling priority. A thread can create another thread within itself by the issuance of the command DosCreateThread. All the threads within a process share all the process’s resources including the address space. This multithreaded model helps the system to achieve high degree of parallelism, concurrent execution, and interactivity. The cost of achieving concurrency is significantly lower than is possible in a single-threaded process system such as UNIX as threads are less expensive to create and maintain.
OS/2 is a preemptive, priority based, multitasking system. The scheduler determines what is the highest priority thread in the system and runs that thread for a time slice or time quantum. The time slice management makes use of dynamic timeslicing to maximize processor utilization for applications. When the time slice expires, the thread is then preempted from the system and the scheduler determines whether another thread is ready to run. The scheduler implements a multilevel priority scheme with dynamic priority variation and round-robin scheduling within a priority level. Dynamic priority variation changes the priority of threads based on their activity to improve the overall performance and responsiveness of the system. Round-robin scheduling ensures all threads at a common priority level to have a fair share of execution.
OS/2 is interrupt driven to allow the processor to be used while I/O is occurring. If an interrupt occurs while a thread is executing, then a thread of higher priority becomes ready to run, while the original thread is preempted to allow the higher priority thread to be executed. But OS/2 does not provide complete preemption. That is a thread can be preempted only when it is running in the user code. If a thread has issued a system call when it is running in the kernel code, the thread will not be preempted, unless it is running in the highest priority class.
The 32-bit OS/2 system supports up to 4095 processes and threads whereas the 16-bit OS/2 supports only 255 processes and 512 threads.
The main goal of the 32-bit programming environment is to provide an architecture that allows applications, subsystems, and the system itself to be portable to processing platforms rather than the uniprocessor Intel 80X86 based machines. This requirement led to the development of a new memory model called flat model, which enables processes to view memory as a large linear address space addressable by 32-bit offsets, rather than a collection of segments, as in the 16-bit OS/2 model. The flat model is easily portable to most processor architectures, since all that the hardware must provide is a base register capable of addressing a large, paged linear address space and an offset register for indexing into the address space. The flat model effectively hides all segmentation from the programmer, resulting in a portable model with much higher performance than a segmented system could provide. This model is also known as the 0:32 memory model, since only the 32-bit offset into the process’s address space is used to develop the address of a single byte of memory.
In this model, the basic unit of allocation and sharing is a 4KB page, and memory is divided not into segments, but rather into memory objects that consists of one or more 4KB pages. The major difference between the flat model and its 16-bit model is the memory protection. In 16-bit model protection is based on per-segment basis. Whereas, in the flat model all application’s memory objects exist within a single large segment.
The OS/2 utilizes virtual memory. The key to virtual memory is that it allows the addresses referenced in a running program to be disassociated from the addresses available in primary storage. A processor’s memory management unit (MMU) provides this feature, which is called address translation. The MMU translates the virtual addresses into physical addresses as instructions are executed. The range of virtual addresses available is called virtual address space, whereas the range of physical addresses available is called physical address space. Virtual memory systems have the characteristic of allowing a program or process to be independent of its actual position in physical memory, whether all or part of that program or process is in physical memory. The address translation between physical and virtual memories occur during run time.
There are two forms of protection. One – Protection is among the processes in the system, which allows each process to have an isolated memory environment in which to run. This environment is called the process virtual address space. By allocating the process virtual address space to each process, we protect the individual processes in the system from one another. The second type of protection provides isolation of the system from the user processes. Here the system virtual address space encompasses the kernel memory and all the process virtual address spaces.
A thread running in user mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process’s virtual address space unless memory sharing between the processes has been set up. A thread running in user mode also cannot access kernel memory. Whereas a thread in kernel mode can access all process virtual address spaces and kernel memory.
The memory management component of the system is responsible for allocating process virtual address spaces and for setting up the required hardware structures to enable processes to be protected from one another and from the system. The memory management API allows threads within a process to manipulate the contents of the process virtual address space. It also provides functions for manipulating memory objects within the process virtual address space. OS/2 provides functions for object allocation, deallocation, and sharing.
Dynamic linking allows the binding of code and data references to be delayed until the program is actually loaded or until the program specifically requests the operating system to link dynamically to a dynamic link library (DLL). The former type of dynamic linking is called load-time dynamic linking, whereas the latter is called run-time dynamic linking. There are two executable modes in OS/2 environment: EXE modules for programs and DLL modules containing shared libraries. Both module types use the OS/2 segmented executable file format, but they are distinguished by a special bit in the executable file header.
Dynamic linking requires imports and exports of code and data objects across EXE or DLL modules. The OS/2 linker allows the programmer to specify that an external reference is in another executable module; this causes the linker to create an import record in the import table of the EXE header that describes the external reference by module name and object name, or ordinal number. The program loading process continues until the program or library is ready to execute. If the system loader is unable to resolve a load time dynamic link request, the program library load is aborted. If necessary one or more DLL may be loaded and fixed up so that the loading of an EXE or a DLL can be completed.
Dynamic linking is a powerful mechanism for providing linkages to shared code and data objects in a multitasking virtual memory environment. It provides an extendible and flexible foundation for meeting the criteria of API abstraction and information hiding. Another benefit of dynamic linking is that EXE files are not as large, since commonly used routines can be placed in a DLL instead of being replicated in each EXE that uses them. This results in saved disk space and potentially faster program loading.
OS/2 can be categorized in two categories: system I/O and user I/O. Processes use system I/O to perform file level; I/O to secondary storage devices managed by the file systems. System I/o is programmed using the file system API. Processes utilize user I/O to interact with the user by employing keyboard, display, and mouse. User I/O is programmed using the keyboard (KBD), mouse (MOU), and video (VIO) subsystems, or the Presentation Manager (PM).
As in DOS, devices in OS/2 are categorized as either block devices or character devices, and the same naming conventions are used. The system uses similar device chain for managing the devices and their names. However, the user I/O devices such as, the keyboard, mouse, and display devices are accessed differently from in DOS. Reentrant subsystems with well-defined APIs allow concurrently executing processes to share the user I/O devices. The block devices are accessed using the file system API as in DOS, and the other character devices are accessed by APIs.
OS/2 supports the FAT file system used by DOS, and consequently can read and write DOS files. Although this capability is desirable from compatibility and migration standpoints, the FAT file system was not originally designed to support many concurrent I/O requests from different processes on large block devices. Therefore, OS/2 provides an alternative file system, called the High Performance File System (HPFS). To provide an architecture in which programs are transparent to the type of file system, OS/2 has an installable file system (IFS). The system has facilities for installing multiple file systems, and a standard file system API to which all installable file systems adhere to.
Each file system supports the management of file system objects, such as files and directories, in a hierarchical fashion. File system objects and devices are managed and accessed by processes using a common file system API. Since the file system API is not sensitive to any of the file system naming conventions, each file system can have its own name structure for the file system objects it supports.
OS/2 device drivers are significantly different from DOS device drivers. Like the kernel they run in the most privileged execution state, privilege level 0. Device drivers have two main entry points: a strategy routine that receives requests from their kernel and an interrupt routine that is called when a hardware interrupt occurs. Since the strategy routine and interrupt routine may both need access to the same structures, the device driver must carefully serialize access to shared structures and manage race conditions between the strategy routines and interrupt routines.
Strategy routine requests are made in the form of request packets that describe the operation. Device drivers perform the requested operation using combination of the hardware and a set of system services created specially for device drivers called the device-help (DevHelp) routines. The I/O features of OS/2 allows device drivers to service multiple requests concurrently and to perform overlapping I/O operations.
The paging feature is not only used to support the flat model and multiple DOS address spaces, but also to allow OS/2 to provide memory overcommitment. The storage can be virtualized on fixed disk media at a much lower I/O cost, because the size of the page is not variable. Also the system can do a better job of tracking memory usage, since memory aging algorithms operate on a page granularity, instead of a segment granularity, resulting in a better memory utilization. Therefore it is a demand paged, virtual memory system and is designed so that the system will run acceptably in nominally overcommited situations.
OS/2 provides the dynamically linked 32-bit API to allow flat-model applications to use the OS/2 system services. The 32-bit API has been designed so that applications and subsystems that use and provide 32-bit APIs will be portable to any future OS/2 platform. The multitasking API provides better thread management in the areas of creation and termination, and the system supports up to
4095 processes and 4095 threads. The 32-bit API uses the Presentation Manager (PM) for managing the user I/O.
OS/2 is a multitasking operating system. The existence of multiple processes and asynchronous concurrent threads implies the need for mechanisms to allow processes to exchange data and to synchronize the execution of their threads. Interprocess communication primitives provide these basic features for data sharing and thread synchronization.
The IPC facilities of the OS/2 system are organized into a tiered hierarchy based on the complexity of the IPC mechanism. The simplest IPC mechanisms are shared memory, semaphores, signals, and exceptions. These constructs are classified as simple constructs, since the processes that use them must communicate with one another explicitly. More abstract IPC mechanisms higher in the hierarchy are built out of the low level mechanisms. Queues and named pipes are examples of higher-level abstractions that allow processes to exchange data and to synchronize their execution. The highest-level abstraction is the API call. Since each API function defines an abstraction and a level of information hiding, these functions manage the usage of any necessary IPCs from requestors. The API abstraction is often used by application programs that build their own API functions into dynamic link libraries that are tailored to their specific needs.
3.8 PRESENTATION MANAGEMENT 3.8.1 SESSION MANAGEMENT Sessions, or screen groups, are managed by the session manager, a component of OS/2. Each session contains a logical keyboard, a logical mouse, a logical display, and a collection of processes that share the logical user I/O devices. The user shell allows the users to start or stop applications, and to select the foreground session. The OS/2 user initiates session switching using the hot key or mouse device, the user-I/O subsystems switch logical device contexts, by changing the per-session, logical-to-physical user I/O device mappings.
3.8.2 PRESENTATION MANAGER The PM is the graphical user interface of OS/2. It extends the functionality of the base user I/O services to include a windowed user interface and device-independent graphic presentations. In a graphical user interface environment, the screen becomes a source of user input. Users use the mouse and keyboard to manipulate intuitive graphic controls displayed on the screen. Examples of these controls are pull-down menus, buttons, scroll bars etc. The PM allows to have a consistent user interface, since the controls for these programs are built into the PM, not into the user programs.
The PM is divided into two functional groups: the windows API and the graphics API. The windows API was derived from the windowing architecture of Microsoft Windows. The graphics API integrates technologies from the IBM Graphics Data Display Manager (GDDM), the IBM 3270 Graphics Control Program (GCP), and the Microsoft Windows Graphics Device Interface (GDI). The PM is an extension to the base OS/2 architecture, and runs on top of the OS/2 kernel in the PM.
session. The PM is a collection of dynamic link libraries and executable programs that runs in user mode.
3.9 DOS COMPATIBILILTY OS/2 provides DOS compatibility using the virtual mode, and uses paging to provide more than one DOS compatibility environment. DOS applications can be run full screen, windowed, or iconized in the background. In addition to being better protected, providing better compatibility, and allowing more DOS sessions, the OS/2 DOS environment leaves applications approximately 620KB in which to execute – more space than is available in DOS. Since DOS environments are swappable, starting many DOS sessions does not drive up the system memory requirements. The DOS environment in OS/2 allows specific versions of DOS to be booted into VDMs, enabling DOS version-dependant applications to run. The OS/2 DOS support provides an extendible OEM architecture that allows the environment to be tailored to emulate any DOS environment.
The OS/2 is an advanced single-user, multitasking personal computer operating system that exploits advanced hardware platforms. It provides a demand-paged system with a 32-bit programming model that is portable to other 32-bit processor architectures. The OS/2 can multitask DOS and Windows applications in a protected environment. OS/2 is compelling because it offers the best system for running 16-bit DOS and Windows applications while moving into the more flexible and powerful 32-bit world. OS/2's object-oriented interface and free technical support are compelling factors. OS/2 is smallest of the three major operating system (Linux, Windows NT, and OS/2) when using a graphical interface. This is the attraction of OS/2. A user need only upgrade to 8MB of RAM to use an object-oriented interface and have a good platform for multitasking DOS, Windows, and OS/2 programs. OS/2 is the strongest of the three for backward compatibility with DOS and Windows. It is a high performance, highly reliable, information accessible, and integrated operating system.
The design of OS/2 by H.M.Deitel and M.S.Kogan
2. “The Design of Operating System/2” by M.S.Kogan – IBM Systems Journal, Vol 27, No. 2,