ABSTRACT Abstract This document is unique in its detailed coverage of OS/2 Warp (PowerPC Edition) architecture. It focuses on the architecture of the microkernel. It provides information about the microkernel based architecture, which will give dramatic advances in computing architecture. This document was written for IBM customers, system engineers, software developers. Basic understanding of OS/2 is assumed. (178 pages) PREFACE.5 Acknowledgments This project was designed and managed by: Lajos Damen International Technical Support Organization, Boca Raton Center Alex Gregor International Technical Support Organization, Boca Raton Center The authors of this document are: Joachim Birke IBM Germany Rudi van Emmenes IBM South-Africa Juliandri Jenie IBM Indonesia Scott Rigby IBM Australia Terje Storstein IBM Norway This publication is the result of a residency conducted at the International Technical Support Organization, Boca Raton Center. Thanks to the following people for the invaluable advice and guidance provided in the production of this document: Scott Bennett IBM OS/2 Warp (PowerPC Edition) Installation development, Boca Raton Craig A. Bennett IBM OS/2 Warp (PowerPC Edition) development, Boca Raton Kenneth W. Borgendale IBM OS/2 Warp (PowerPC Edition) architect, Boca Raton Arnold H. Bramnick IBM OS/2 Warp (PowerPC Edition) development, Boca Raton Mike Cooper IBM OS/2 Warp (PowerPC Edition) development, Boca Raton Robyn L. Focazio IBM Microkernel development, Austin Steve C. Heuer IBM Microkernel development, Austin Bryon S. Neitzel IBM OS/2 Warp (PowerPC Edition) MVM development, Boca Raton Chris P. Perritt IBM OS/2 Warp (PowerPC Edition) development, Boca Raton Pete C. Rodriguez IBM OS/2 Warp (PowerPC Edition) Installation development, Boca Raton James R. Schoech IBM OS/2 Warp (PowerPC Edition) development, Boca Raton Jim White IBM Boca Raton Kenneth E. White IBM OS/2 Warp (PowerPC Edition) development, Boca Raton CONTENTS Table of Contents COVER Book Cover NOTICES Notices EDITION Edition Notice ABSTRACT Abstract CONTENTS Table of Contents FIGURES Figures TABLES Tables FRONT_1 Special Notices PREFACE Preface PREFACE.1 How This Document is Organized PREFACE.2 Related Publications PREFACE.3 International Technical Support Organization Publications PREFACE.4 ITSO Redbooks on the World Wide Web (WWW) PREFACE.5 Acknowledgments 1.0 Chapter 1. Introduction 2.0 Chapter 2. The IBM Microkernel 2.1 Elements of the IBM Microkernel 2.1.1 Physical Resource Management 2.1.2 I/O Support 2.1.3 Inter Process Communication (IPC) 2.1.4 Tasks and Threads 2.1.5 Virtual Memory Management 2.2 Elements of the IBM Microkernel Services 2.2.1 Initializing the Microkernel Services 2.2.2 Task Manager 2.2.3 External Memory Managers 2.2.4 Default Pager 2.2.5 Root Name Server 3.0 Chapter 3. System Services 3.1 Device Support 3.2 Event and Window Services 3.2.1 Screen Group and Session Management 3.2.2 Event Services 3.3 File Services 3.3.1 File Service Client 3.3.2 File Services Server 3.3.3 Thread and Port Model 3.3.4 File Services Pager 3.3.5 Physical File System (PFS) 3.3.6 Volume Manager 3.4 Pipe Services 4.0 Chapter 4. OS/2 Functions 4.1 OS/2 Server 4.1.1 OS/2 Server Architecture 4.1.2 Configuration 4.1.3 Components Of The OS/2 Server 4.1.4 Loader 4.1.5 Startup 4.1.6 Shutdown 4.2 The MVM Environment 4.2.1 OS/2 Warp (Intel) Multiple Virtual DOS Machine 4.2.2 OS/2 Warp Connect (PowerPC Edition) MVM Environment 4.2.3 Installation 4.2.4 Multiple Virtual Machine Server 4.2.5 EM86 (8086 Emulation) 4.2.6 Instruction Set Translator 4.2.7 DOS Emulation 4.2.8 Virtual Device Drivers 4.2.9 Windows Support 4.2.10 Changes to The Command Set 4.2.11 Changes to the MVM DOS Settings 4.3 Graphics Subsystem 4.3.1 Graphics Subsystem Overview 4.3.2 Graphics Engine 4.3.3 PM Video Device Driver 4.3.4 Base Video Services 4.3.5 Fonts 4.4 Graphics Subsystem Summary 4.5 Printing Services 4.5.1 Spooler Objects 4.5.2 Printing from DOS and Windows 4.5.3 Printer Driver Support 4.6 System Management. 4.6.1 Installation 4.6.2 System Management Initialization Process 4.6.3 Serviceability Tools 4.6.4 Vital Product Data 5.0 Chapter 5. Installation 5.1 Media Preparation 5.1.1 Partitioning 5.1.2 System Migration 5.2 Feature Install 5.2.1 Feature Install Catalog 5.2.2 Drag and Drop Install 5.2.3 Install Objects 5.2.4 Inventory Objects 5.3 Inventory Information 5.4 CID and Unattended Installation Support 5.4.1 Standard Keywords 5.5 Tracing Installation Problems 5.5.1 Media Preparation 5.5.2 Feature Install 6.0 Chapter 6. Application Support 6.1 Application Development A.0 Appendix A. Changes to MVM DOS Settings GLOSSARY Glossary ABBREVIATIONS List of Abbreviations INDEX Index COMMENTS ITSO Technical Bulletin Evaluation RED000 1.0 Chapter 1. Introduction OS/2 is now, for the first time, running on a different platform from the Intel based personal computer. It now also runs on systems based on the PowerPC architecture defined by the Apple, IBM and Motorola alliance. The implementation of OS/2 Warp Connect (PowerPC Edition) is based on the IBM microkernel. The IBM microkernel is the foundation for a set of highly portable systems. The microkernel provides a way of structuring systems software to reduce complexity and increase its flexibility and portability. The microkernel contains a small, message passing nucleus of system software running in the most privileged state of the computer that controls the basic operation of the machine. The IBM microkernel includes the microkernel and a set of servers and device drivers that provide microkernel services. The functions performed by the microkernel are limited in order to reduce its size and to maximize the amount of code that runs outside the kernel. The microkernel includes only those functions required to provide a set of abstract processing environments for application programs and to permit applications to work together to provide services and acts as clients and servers. Many other operating system functions, such as file systems, device support, and traditional programming interfaces are placed outside of the microkernel for possible reuse of other operating systems developers. The IBM microkernel uses technology from the Carnegie Mellon University MACH Research Project. The IBM microkernel also incorporates selected technology developed by the Open Software Foundations Research Institute. This book gives you a first look in the components of OS/2 Warp Connect (PowerPC Edition) as depicted in Figure 1. Figure 1. OS/2 Warp Connect (PowerPC Edition) Components The IBM microkernel and the microkernel services are described in Chapter 2, "The IBM Microkernel" in topic 2.0. The system services depicted in Figure 1 consist of the services which might be useful to other operating system developers using the microkernel as a base. The system services are: ø Event and window services The main part of the session management of OS/2 is handled by this component. Event and window services are also responsible for handling all keyboard and mouse (and any other locator device) input. ø File services Are responsible for handling all the file requests in OS/2 Warp Connect (PowerPC Edition). ø Pipe services All the pipe requests presented by application programs to the DOSCALLS.DLL API library are managed by the pipe server. The system services are described in Chapter 3, "System Services" in topic 3.0. Chapter 4, "OS/2 Functions" in topic 4.0 describes the OS/2 Control Program and the Dos/Windows support of OS/2 Warp Connect (PowerPC Edition). The presentation services, which consist of the user interface, and the components necessary to support it, are the topics of "Graphics Subsystem" in topic 4.3. To use the system, it has to be installed on a PowerPC-based machine. This process is described in Chapter 5, "Installation" in topic 5.0. Applications supported, application migration considerations and applications development, are the topics of Chapter 6, "Application Support" in topic 6.0. 2.0 Chapter 2. The IBM Microkernel The OS/2 Warp Connect (PowerPC Edition) product is based on the microkernel technology as shown in Figure 1 in topic 1.0. The idea of a microkernel-based operating system dates back to 1986, when a team of researchers at Carnegie-Mellon University addressed several UNIX problems, mainly concerning the inability to extend the UNIX operating system due to its layered structure and the difficulty to easily port an application from one vendor specific UNIX version to another vendor specific UNIX version. The team at Carnegie-Mellon University solved this problem by designing a client/server and message based microkernel, called Mach. The IBM microkernel is based on this MACH microkernel and it also incorporates selected technology developed by the Open Software Foundation Research Institute. Additionally, IBM has made several improvements to the microkernel in order to get a solid base for the OS/2 Warp Connect (PowerPC Edition) product. The IBM microkernel provides the following comprehensive environment for operating systems: ø Multiprocessing ø Multithreading ø Interprocess communication ø Extensible memory management ø Support for multiple operating personalities The IBM microkernel also provides a concise set of IBM microkernel services implemented as a pure kernel and an extensive set of services for building operating system personalities implemented as a set of user-level servers. Functions of the IBM microkernel include the following: ø Providing common programming for low-level system elements, such as device drivers and file systems. ø Exploiting parallelism in both operating system and user applications. ø Supporting large address spaces with flexible memory sharing. ø Allowing transparent network resource access. ø Enabling compatibility with existing software environments, such as OS/2 and DOS/Windows. ø Enabling portability (to 32-bit and 64-bit platforms). Subtopics: 2.1 Elements of the IBM Microkernel 2.2 Elements of the IBM Microkernel Services 2.1 Elements of the IBM Microkernel The IBM microkernel provides the following small set of abstractions: ø Task Unit of resource allocation: large address space and port right ø Thread Unit of CPU utilization: lightweight (low overhead) ø Port A communication channel accessible only through the send/receive capabilities or rights ø Memory object The internal unit of memory management The functions performed by the microkernel are limited in order to reduce its size and maximize the amount of code that runs outside the kernel. The microkernel includes only those functions required to provide a set of abstract processing environments for application programs and to permit applications to work together to provide services and act as clients and servers. The five type of services are: 1. Physical resource management 2. I/O support and interrupt management 3. Interprocess communication (IPC) 4. Tasks and threads 5. Virtual memory management These services offered by the IBM microkernel will be described in more detail in the following paragraphs. Subtopics: 2.1.1 Physical Resource Management 2.1.2 I/O Support 2.1.3 Inter Process Communication (IPC) 2.1.4 Tasks and Threads 2.1.5 Virtual Memory Management 2.1.1 Physical Resource Management The IBM microkernel brings the various resources it maintains to virtual memory. However, all actions performed depend on the underlying physical resources of the IBM microkernel. Host Machines A host is the multiprocessor as a whole. Each host (uniprocessor or multiprocessor) in a networked IBM microkernel system runs its own instantiation of the IBM microkernel. The host multiprocessor is not generally manipulated by client tasks. But, because each host does carry its own IBM microkernel, each with its own port space, physical memory, and other resources, the executing host is visible and sometimes manipulated directly. Also, each host generates its own statistics. Hosts are named by a name port, which is freely distributed and can be used to obtain information about the host, and a control port, which is closely held and can be used to manipulate the host. Operations supported by hosts include the following: ø Clock manipulation ø Statistics gathering ø System reboot ø Setting the default memory manager ø Obtaining lists of processors and processor sets ø Accessing hardware Physical Processors A physical processor is a unit capable of executing threads. Each physical processor is named by a processor control port. Although significant in that they perform the real work, processors are not very significant in the microkernel, other than as members of a processor set. It is a processor set that performs the basis for the pool of processors that is used to schedule a set of threads and has scheduling attributes associated with it. Processor Sets Processors are grouped into processor sets. A processor belongs to only one processor set. A processor set forms a pool of processors used to schedule the threads assigned to that processor set. A processor set exists as a basis to uniformly control the schedulability of a set of threads. The notion also provides a way to perform coarse allocation of processors to given activities in the system. A host contains a number of processor sets, including a default processor set. The operations supported upon processor sets include the following: ø Creation and deletion ø Assignment of processors ø Assignment of threads and tasks ø Scheduling control Clocks A clock provides a representation of the passage of time by incrementing a time value counter at a constant frequency. Each host or node in a multicomputer implements its own set of clocks based upon the various clocks and timers supported by the hardware as well as abstract clocks built upon these timers. The set of clocks implemented by a given system is set at configuration time. Each clock is named by both a name and a control or privileged port. The control port allows the time and resolution of the clock to be set. Given the name port, a task can perform the following: ø Determine the time and resolution of the clock ø Generate a memory object that maps the time value ø Sleep (delay) until a given time ø Request a notification or alarm at a given time The clock facility implements one or more of the following clocks: ø The REALTIME clock which measures with moderate resolution the time since system initialization. ø The standard defined BATTERY clock with low resolution which provides a time value that is controlled exclusively by user-level code. ø The standard defined HIGHRES clock which enables high-resolution alarm services. Physical Memory The various IBM microkernel objects and associated data structures occupy physical memory. It is a hardware- and implementation-dependent issue as to which of these structures can be swapped or paged out of memory. Currently, clients have no control over this memory, except to the extent that they create kernel-managed entities. The majority of the system's physical memory forms a single paging pool. The pool of pages forms a cache for the virtual memory system. The set of pages that resides in physical memory at any given time is decided by the page-replacement algorithm, implemented in the kernel. Clients have no control over this algorithm, with the exception of the vm_wire call which forces a region of virtual memory to be and stay resident. Even external memory managers have no influence; if they do not respond fast enough to a request to write a page, the default memory manager is used to move the page from physical memory to system paging storage. When a memory object is no longer referenced, the kernel normally frees all of its physical memory pages. A memory manager can mark an object's pages as cacheable, meaning that the object's pages are moved to a free list but are not destroyed. This is usually specified for memory objects that persist. 2.1.2 I/O Support A modern computer system may support a wide range of buses, controllers, and devices. The configuration services are responsible for locating and managing all of the I/O related hardware resources that are visible to the software in the system. They determine what I/O hardware is present and grant device code access to it. These configuration services consist of: ø The configuration manager, which identifies the machine and any built-in hardware. ø The device manager, which is responsible for starting the device drivers. ø The resource manager, which controls this process. In order to support I/O and device access, the microkernel provides access to I/O resources, such as memory-mapped devices, I/O ports, and direct memory access (DMA) channels. The DMA interfaces are used in providing information and in programming certain hardware functions to transfer data between memory and a device. 2.1.3 Inter Process Communication (IPC) The majority of interactions between an IBM microkernel task and its environment are accomplished by sending and receiving messages. To facilitate this, the microkernel provides synchronous one-way messaging as well as a Remote Procedure Call (RPC) mechanism. Regardless of the mechanism employed, all forms of IPC occur over IBM microkernel-provided communication channels known as ports. Ports A port is a unidirectional communication channel between a client that requests a service and a server that provides the service. A port has a single receiver (server) and potentially multiple senders (clients) which are connected in a secure fashion. With the exception of the task's virtual address space, all other system resources are accessed through ports. Any given entity can have multiple ports that represent it, each implying different sets of permissable operations. For example, many entities have a name port and a control port that is sometimes called the privileged port. Access to the control port allows the entity to be manipulated. Access to the name port simply names the entity, for example, to return information. There is no system-wide name space for ports. A thread can access only the ports known to its containing task (port name space, see below). A task holds a set of port rights, each of which names a (not necessarily distinct) port and which specifies the rights permitted for that port. Every port is created as an instance of a port class. When created, a single receive right (creator is server) for the port is established and also added to the specified port name space. Port Name Space (Portspace) Port rights (port names) cannot be accessed directly but, instead, are accumulated in port name spaces. The port name space assigns a local name, for the right, that is used to access the right. Each task is associated with a port name space that provides the context for interpreting names into rights for all threads. The names assigned within a port name space are completely at the discretion of the Inter Process Communication (IPC) system. The user has no control over these names, but the following guarantees are made: ø Receive and send (including the send-once restricted form) rights to the same port coalesce to a single port name. That is, if a port name space holds three send rights and a single receive right for a port, it will have a single name for all four rights. ø Send rights are reference counted but only a single receive right can exist for a port or port set. ø Port names are freed when all the reference counts go to zero. Because a port name space is bound to its owning task, it is created and destroyed with its owning task. Port Classes A port class defines the format of messages that can be transferred across ports of this class. A port class may also be created as a combination of the signature of a base port class and a specified new signature (signatures are described in the messages section). Most ports have well defined messages that are passed across them. This approach allows these formats to be preregistered with the IPC system once, avoiding the overhead of verifying their correctness on each message transfer. After the port class is created, its message format can never change. Additionally, the port class associated with a port cannot change and it also cannot be explicitly destroyed. Instead, the port class will be retained until the last reference to the port class goes away. Port Rights Because of their fundamental nature in the workings of the microkernel system, ports are strongly protected. A port can be accessed only according to the set of capabilities granted by the user. These capabilities, known as port rights, are maintained on a port name space basis. Each task has an associated port name space, and therefore can have a unique combination of port rights for a particular port. This capability notion is the fundamental security model and mechanism exported by the IBM microkernel. The following port rights are maintained by the Inter Process Communication (IPC) system: ø Receive right This capability enables the holder to receive messages from the port (holder acts as a server). Only a single receive right exists for a port, and after it is destroyed it cannot be recreated. Therefore, a port whose receive right has been destroyed is considered dead. The receive right also gives the holder the right to make send rights for the port. ø Send right This capability enables the holder to send unlimited messages over the port. Many send rights (clients) can exist for a single port. ø Send-once right This capability enables the holder to send a single message over a port. Many send-once rights can exist for a single port. Notifications Many tasks using a port can be notified, through a kernel-generated Remote Procedure Call (RPC), when certain state transitions occur relative to the port. Such notifications are requested when one of the following conditions occur: ø Dead-Name state When the receive right for a port is destroyed (server does not exist anymore) this port is considered to have died. Any task which holds a send right for this port can be notified of this state transition, when a registration has been acquired accordingly. ø No-More-Senders state When the last send or send-once right for a port is deallocated, the port is equally unusable for message transmission. The holder of the receive right for the port might be interested in this event in order to perform garbage collection of resources associated with the port. Such tasks can register for no-more-senders notifications. Port Sets A port set is a means of collecting a number of receive rights together into a single unit for message-receipt purposes. When a receive operation is performed against a port set, a message will be received at random from one of the ports in the set. It is not allowed to directly receive a message from a port that is a member of a port set. There is no notion of priority for the ports in a port set. The port set has its own name. A receive right can belong to only one port set. Messages A message is a structured collection of direct data, indirect data, and port rights passed between two entities through transmission over a port. The message itself consists solely of data, addresses and port right names. Its contents are interpreted based upon the signature registered for the port in order to facilitate the data transfer. For each particular port there may exist several message IDs and for each message ID there is one signature which describes the elements of this message. Thus, all signatures belonging to a particular port are described in a data structure called signature collection, which has the following contents: ø The size, in bytes, of the signature collection ø A contiguous range of message IDs that are valid on the port ø An array of offsets into the signature collection for each message ID's signature Message Transmission The fundamental microkernel mechanism for message transmission is a form of two-way messaging most closely related to Remote Procedure Call (RPC) implementations. However, if the signature for a particular message ID defines no return data, the client may choose to send the message as a one-way message by invoking a special interface. The following applies when messages are sent: ø The interpretation and transmission of the supplied message buffer is driven by the message signature. ø All memory-addressing errors are handled through exceptions, not by returning errors. The offending task will be terminated, unless the exception is handled. ø All other errors are reported synchronously through return codes from the messages APIs. ø Resource shortages in the sender, receiver, or kernel will cause message transmission be silently blocked until resources become available. As already mentioned, there are two type of interprocess communication within the microkernel environment: the Remote Procedure Call (RPC) and the one-way message. Remote Procedure Call (RPC) Although it is possible to emulate the RPC at user level through the use of two ports and the one-way message-passing, such an approach could not equal the performance offered by a kernel-supplied primitive tuned for RPC. With this approach, a sender supplied reply port is not needed as the microkernel RPC maintains a reply port inside the kernel, thus avoiding overhead. Additional overhead at user-level code is avoided because verifying messages on reply is not necessary because the reply message format comes from the same signature. Figure 2 shows the kernel-supplied reply ports and the RPC linkage between the client and the server. ________________________________________________________________________ | | | | | | | | | | | | | | | | |________________________________________________________________________| Figure 2. RPC Linkage between Client and Server One-Way Inter Process Communication In a one-way IPC, a message is sent without expecting a reply. The signature for the corresponding message ID must specify that no reply data is required. Unlike RPC, as soon as the data transfer to the server is complete, the corresponding call completes. Server Thread Support A common practice is to have a set of threads in a task dedicated to receiving messages and generating replies (where appropriate). This is the sole function of these threads. Because this approach is so common, the microkernel provides direct support for this practice. After a thread has been made a message server, it cannot be safely removed from its task without running the risks associated with nonrestartable aborts. Message Interface Generator The Message Interface Generator is a program that generates Remote Procedure Call (RPC) code for communication between a client and a server process. To use the Message Interface Generator the user has to provide a specification file which defines the parameters for the message passing interface and the procedure call interface. Due to the contents of the specification file the Message Interface Generator generates three files: ø User (Client) Interface Module: It implements and exports procedures and functions to send and receive the appropriate messages to and from the server. ø User (Client) Header Module: It defines the types and routines needed at compilation time. ø Server Interface Module: It extracts the input parameters from an IPC message and calls a server procedure to perform the operation. When this procedure returns, the generated interface module returns the procedures return code in the reply message with all output parameters sent by reference. Note that this generated module does not perform the action of receiving or sending messaging, only the interpretation and processing of messages. Instead, the Message Interface Generator provides a "demultiplexer (demux)" function, which, after having interpreted the incoming message, calls the desired function to perform the actual work. 2.1.4 Tasks and Threads The IBM microkernel architecture defines tasks and threads in order to support parallel execution. This is done by separating the execution environment (tasks) from the execution of instruction streams (threads). That means, a task does not execute itself. Threads are the active and computational entities. So, by saying "task A does X", it is meant, that "a thread contained within task A does X". Subtopics: 2.1.4.1 Tasks 2.1.4.2 Threads 2.1.4.3 C-Threads 2.1.4.1 Tasks A task is a container to hold references to resources in the form of: ø A port name space ø A virtual address space ø A set of threads All tasks are tagged with a security token, an identifier that is opaque from the IBM microkernel's point of view. It encodes the identity and other security attributes of the task. This security token is included as an implicit value in all messages sent by the task. A new task is created based on an existing prototype task. The new task: ø Has either an empty virtual address space or one inherited from the parent task. ø Inherits the security token from its parent task. ø Has an empty port name space. ø Contains no threads. The new (child) task receives the following special ports, which are created or copied at task creation: ø Task-self port The port by which the kernel knows the new child task and allows it to be manipulated. The child task holds a send right for this port. This port name is also returned to the calling task. ø Bootstrap port The port to which the child port can send a message requesting return of any system service port it needs. The child task inherits a send right for this port from the parent task. ø Host-self port The port by which the child task requests information about its host. The child task inherits a send right for this port from the parent task. Priority As threads are the only computational entities within a task, the priority of a task has only an effect on containing tasks, that is the priority of a new thread is set to match the priority of the enclosing task. 2.1.4.2 Threads As already mentioned, threads are the basic computational, active entities in the IBM microkernel. A thread is a lightweight entity which is inexpensive to create and requires low overhead to operate. Its owning task bears the burden of resource management. On a multiprocessor, it is possible for multiple threads in a task to execute in parallel. A thread belongs to only one task that defines its virtual address space and a port name space with which other resources are accessed. A thread has the following features: ø A point-of-control flow in a task or a stream-of-instruction execution. ø Access to all the elements of the containing task. ø Parallel execution with other threads, even threads within the same task. ø Minimal state for low overhead. A thread has the following set of states: ø Machine state It changes as the thread executes and can also be changed by another holder of the corresponding IBM microkernel thread port. But care should be taken to set the state of the thread because inconsistency may occur. ø A set of thread-specific port rights This set identifies the thread's microkernel port, a reply port maintained for the thread by the kernel, and ports used to send exception messages on behalf of the thread. ø Suspend count Is nonzero if the thread is not to execute instructions. ø Resource scheduling parameters For example, assignment to a specific processor set or scheduling policy for a corresponding processor set. ø Thread security token Provides a thread override to the task proxy security token. Priority and Scheduling A thread is scheduled for execution according to its current priority and the scheduling policy currently set for the thread's assigned processor set. There are scheduling policies defined, such as: ø POLICY_TIMESHARE ø POLICY_RR (round robin) ø POLICY_FIFO (first-in, first-out) Threads have three priorities associated with them by the system: ø A priority value that can be set by the thread to any value up to a maximum priority. ø A maximum priority value that can be raised only through privileged operation so that users cannot unfairly compete with other users in their processor set. ø A scheduled priority value used to make scheduling decisions for the thread. This value is determined on the basis of the user priority value by the scheduling policy. Processor Sets As already mentioned, tasks are assigned to a specific processor set. When a new thread is created in that task, this thread inherits the corresponding processor set. However, a thread can be assigned a different processor set. Traps and Exception Processing To affect the structure of the address space or to reference any resource other than the address space, the thread must execute a special trap instruction. This causes the IBM microkernel to perform operations on behalf of the thread or to send a message to an agent on behalf of the thread. These traps manipulate resources associated with the task containing the thread. Scheduling Support Traps Normally, threads are preemptively scheduled by the microkernel according to its scheduling policies. When a thread wants to give up the processor it can do so by issuing the thread_switch trap by specifying another thread to run. Another scheduling trap is the clock_sleep trap, which delays the invoking thread until a specified time. Identity Traps These traps are used by the thread in order to initially obtain the port rights for itself and its task. Message Send and Receive Traps The most important set of the IBM microkernel traps are those used to send and receive messages or make and service Remote Procedure Call (RPC). Exception processing When an exception occurs in a thread, the thread executes in kernel context and sends a message whose contents describe the exception to an exception port. For any given exception, two exception ports apply: ø A thread-specific type of exception ø A task port for the specific type of exception The type of exceptions for which the exception ports applies are, for example: ø Arithmetic exception ø Could not access memory ø Invalid or undefined instruction or operand ø Software generated exception After an exception, the kernel selects the thread-specific port for the specific type of exception as the destination or the exception message (if it is defined). Whereas a successful reply causes the thread to continue, an unsuccessful reply causes the kernel to send an exception message to the task port for the specific exception. If neither exception message receives a successful reply, the thread is terminated. Not every exceptional condition that a thread encounters is handled this way. A page-not-resident does not send a message to the exception port. Instead, a message is sent to the external memory manager associated with the memory page in which the faulting address lies. Creating Kernel Threads and Tasks For the sake of its own operation, the kernel creates kernel threads that execute purely within kernel context to provide various support functions. For example, page-out function, thread reclamation, and scheduler priority computations are performed by dedicated threads, rather than being executed in interrupt or software interrupt context. Users of the system, including privileged ones, have no direct control over these internal threads. To provide a task context for these threads, the kernel constructs a kernel task to contain them. 2.1.4.3 C-Threads The IBM microkernel provides a set of low-level, language-independent primitives for manipulating kernel-level threads of control in support of multithreaded programming as described in the foregoing sections. Additionally, there is a C-Threads package, which is a run-time library that provides user-level threading as well as a C language interface to these facilities. The constructs provided are as follows: ø Forking and joining of threads ø Protection of critical regions with mutex variables ø Synchronization by means of condition variables A set of C threads can execute in parallel on multiple processors within a system. There is a one-to-one mapping of C threads to kernel level threads. 2.1.5 Virtual Memory Management In order to describe the basic mechanisms of virtual memory management, the following elements will be defined: Memory object A memory object is an abstract image of a set of ordered bytes. All data in the system is represented by memory objects. Memory objects can be referenced by mapping portions of the memory object into a range of virtual addresses in the virtual address space. Memory Manager A memory manager is a microkernel task that maintains a set of memory objects. For example, a file in the file system could be represented as a memory object in order to provide memory mapped access to that file. This memory manager may be the pager component of a file system that maintains the abstract image of the memory object on a permanent backing media. Virtual address space A virtual address space consists of a range of virtual addresses, beginning at a minimum virtual address and extending to a maximum virtual address. The virtual address space is divided into virtual pages. Virtual pages are cached in physical memory. As in all virtual memory systems, the total size of all the memory object currently being referenced can be greater than the amount of physical memory in the system. Creating Virtual Address Spaces A virtual address space is created when a task is created and destroyed when the task is destroyed. Normally the new task inherits the virtual address space of its parent task, for example it acquires shared or copied parts of the parent's address space. Alternatively, a child task can be created with an empty address space. Allocating Virtual Memory Allocating virtual memory can be done in two ways which results in either: ø A mapping of a portion of a memory object into the virtual address space ø A range of memory initialized with zeros (anonymous memory) Working with Virtual Memory There are functions provided by the kernel to copy virtual memory from one task to a different one as well as within the own virtual address space. In order to prevent random allocation of virtual memory within a specific region of the virtual address space, this region might be reserved. Setting the Protection/Inheritance Attribute Access permission for a specific virtual address region are: ø VM_PROT_NONE ø VM_PROT_READ ø VM_PROT_WRITE ø VM_PROT_EXECUTE ø Any combination thereof Note that enforcement of protection attributes as well as combinations are machine-dependent. This is also valid for the semantics of attributes or combinations of attributes. For example, for some hardware platforms write access implies read access and execute access cannot be distinguished from read access. Each virtual address region has a maximum and a current protection. The current protection must be a subset of the maximum protection. The maximum protection cannot be changed to include additional protection accesses. Using Virtual Address 0 Some programs fail if memory is allocated at address 0, because they consider a memory pointer whose value is 0 to be a null pointer and not a pointer to a valid memory byte. But some functions may allocate a region at address 0. To prevent the kernel from doing this, the first page at address 0 should be reserved. 2.2 Elements of the IBM Microkernel Services The microkernel services portion of the IBM microkernel system consists of services built on the underlying microkernel. These services provide some functions that the kernel itself depends on, as well a basic set of user-level services for the construction of programs. The microkernel services can serve requests from multiple operating system personality clients and are used to construct the operating system personalities themselves. In addition to the libraries that define the microkernel services, many libraries exist within the microkernel services that are part of the microkernel proper. These libraries represent the interfaces that the microkernel exports and the support logic for the Message Interface Generator (MIG), which is used with the IBM microkernel's interprocess communication facilities. A key element of the microkernel services environment is that it does not constitute a complete operating system. Instead, the microkernel services depend on the existence of a dominant personality, in this case OS/2 Warp Connect (PowerPC Edition). The IBM microkernel is also dependent on some elements of microkernel services. There are cases in which it sends messages to personality-neutral servers to complete internal kernel operations. For example, in resolving a page-fault, the IBM microkernel may send a message to the default pager. The default pager then reads in the page that the kernel needs from a hard disk. Although the page fault is usually being resolved on behalf of a user task, the kernel is the sender of the message. Subtopics: 2.2.1 Initializing the Microkernel Services 2.2.2 Task Manager 2.2.3 External Memory Managers 2.2.4 Default Pager 2.2.5 Root Name Server 2.2.1 Initializing the Microkernel Services The microkernel service for initialization consists of two distinct pieces: 1. An underlying Boot Loader (BL) that loads an image containing the microkernel 2. The bootstrap task Boot Loader The first program run when an IBM microkernel system starts is called the Boot Loader (BL). It is loaded by the firmware of the machine from the boot device into memory and then starts loading other programs and files into memory as proscribed by a configuration file that also resides on the disk. The configuration file contains the name of the microkernel to load, the name of the initial task, the names of other programs and files to load, along with any other information that is needed by later stages of the boot process. In the IBM microkernel system, the initial task started by the boot loader is called the bootstrap task. This task is the first of the microkernel services tasks to be started. Bootstrap Task The bootstrap task has no device drivers built into it, and thus cannot access the hard disk. It can however, access information that the boot loader (BL) has already placed in memory. This information contains all that is needed for the bootstrap task to start tasks running. Once it has started, the bootstrap task becomes a file server for the programs that it starts. As a file server, the bootstrap task serves out the other files that were read into memory by the Boot Loader. The bootstrap task performs the following (in order): 1. Starts the Root Name Server. 2. Starts the Default Pager. 3. Starts the Task manager. 4. Provides File Services (which will be used by the Task Manager). 5. Directs the Task Manager to start to personality neutral (PN) servers required to bring up the dominant personality. PN servers include Message Logger, Hardware Resource Manager (HRM), Bus Walkers, and Device Drivers. 6. Starts the Personality. The bootstrap task continues to behave as a file server until it terminates. 2.2.2 Task Manager The task manager is a microkernel service that completes the boot process and can then be left to load programs or attach new libraries to already running programs. The task manager maintains a set of event/action lists. The event/action lists describe what actions, usually loading a program, take place when a certain event occurs. The events usually contained in the event/action lists are name service notifications. The task manager requests that the name service notify it when certain changes are made to the name space. When the name service notifies the task manager that a change has occurred, the task manager scans through the event/action lists until a match is made against one of them. When the match is made, the indicated set of actions is taken. This mechanism provides for an automatic configuration of the system based on what services are present in the system and what is needed by the system rather than by a fixed set of scripts. By providing such a mechanism, it becomes harder for the system to be configured incorrectly either by attempting to use services that are not present or providing services that will not be used. There are five submodules in the task manager, as follows: ø Extended Link Format (ELF) object loader The ELF loader loads other microkernel services, such as microkernel services servers and device drivers. ø Shared Library Management Shared libraries can be linked at load time using the shared library management utility program. ø Microkernel Services server management The microkernel services server management module provides a set of APIs to load, start, and terminate microkernel services tasks. ø Name Services Name access service is provided to privileged system management software for retrieving task control ports, as well as other information. ø Boot message logging The boot message logging service provides a unified method for all microkernel services tasks to log their errors. 2.2.3 External Memory Managers Memory objects are managed by memory managers. Unlike some virtual memory systems, memory managers are not part of the kernel, but are user mode tasks. Memory managers must register with the kernel. The memory manager and the kernel exchange send rights to two ports that are used by the kernel and the memory manager to communicate. The kernel calls the memory manager on one of these ports whereas the memory manager calls the kernel on the other port. However, creation, representation, and destruction of memory objects is a private responsibility of the memory manager. The kernel deals only with managing the cached pages of memory objects. When a client wants to get access to a memory object or a portion of a memory object, this part of the memory object has to be mapped into the client's virtual address space. The client does this by issuing a corresponding vm_map call. The kernel passes this request to the memory manager. The memory manager is notified by the kernel during the mapping process that the kernel is preparing to cache pages for a memory object. The memory manager declares the memory object attributes. Memory object attributes define the options and customized characteristics of the memory object. When the system runs out of physical pages in order to satisfy a certain request, the kernel selects pages to be evicted from the cache to make room for memory object pages of greater demand. These pages are returned to the memory manager so that these pages can be removed from physical memory. Pages, that have not been updated can be discarded without being returned to the memory manager. Pages that have been updated are called "dirty" and are returned to the memory manager in order for the memory manager to update its abstract image of the memory object. Pages can be declared as "precious", in which case the pages are returned to the memory manager whether dirty or not. 2.2.4 Default Pager The IBM microkernel provides a default memory manager, called the default pager, to manage temporary nonpersistent memory objects. The default pager has a paging space (backing storage) to hold the contents of these memory objects when the kernel needs to use physical storage for some other purpose. Memory backed by the default pager is called anonymous memory. It is valid to have a memory manager that keeps its abstract memory object image in anonymous memory and does not stage the memory object to a backing store. In this case, the anonymous memory, which is managed by the default pager, may be evicted to the default pager's backing space. This is called double paging and should be done, knowing that system resources will be used to maintain this data. 2.2.5 Root Name Server The name space acts as a directory (or depository) to store and locate information about resources currently available in the system and which should be known to other components of the system. The resources described in the name space include: ø Configuration information ø Port addresses ø Service providers ø Directories ø Files ø Personality Dependent (PD) resources ø Personality Neutral (PN) resources Name Space Definition: ø Permanent: Some parts of the name space are permanent from boot to boot unless the system configuration is modified. ø Transient: All other portions of the system are being defined as "transient" and are not saved and restored from boot to boot. ø Rules: With the exception of nodes attached directly to the root (ns_root_dir) of the global name space by the system at installation time, all name space nodes are transient unless they are specifically created as permanent. Structure of the Name Space The namespace of the IBM microkernel is a graph. Each graph is a collection of nodes. The nodes are connected by links. The entire name space exists as a directed graph. In many respects it also has the characteristics of a rooted tree. All name space nodes originate from a single root. Most tasks make use of the namespace by doing one of the following: ø Find services or resources it needs. ø Advertise services or resources it manages. ø Being a name server itself. The name space is not managed by a single server. As an example, there might be multiple file servers, each one managing a subset of the name space. The name server that manages the Root Directory is called the root name server. The collection of all name servers in a system implements the name space graph. These name servers might have different capabilities, that is, not all name servers implement the same set of application programming interfaces. Each name server owns a subset of a name space (sub-graph). Thus, the name space is "fractured", and these fractures are called name borders. Note, that there are no restrictions to force a tree structure, to preclude cycles, or to force the sub-graph to be connected. Figure 3 shows the structure of the root name space and its relationship to other private name spaces. Note, that the dotted line does not denote a link. ________________________________________________________________________ | | | | | | | | | | | | | | | | |________________________________________________________________________| Figure 3. Root and Private Name Space Links A link maps a node and a name to a node. There are two restrictions placed on links: ø A link cannot cross name borders. The two nodes that are connected by a link must be managed by the same name server. ø The two nodes connected by a link must exist. If the node that the link points to is deleted, then the link is also deleted. Nodes Nodes are the data containers of the name space. Each node has a type, a set of zero or more attributes and an access control list (ACL). ACLs are the only mechanism used to protect the integrity of the name space, thus it is important to properly protect directory nodes. Attributes are used to store information and are pairs made up of a name and a value. The name is a possibly empty unicode string. Thus, the name server provides more than just a naming service. It is also an information repository and a powerful query facility can be used to navigate the name space based on this information. There are three types of nodes: ø Directory nodes Nodes that contain outgoing links to other nodes. However, directory nodes can be empty, that is, they have no outgoing links. Directory nodes can be used in much the same way that they are used in a file system. Related items are grouped together and organized within the name space. For example, different devices can be found under the devices directory. There is a special directory node called the root directory node (ns_root_dir) which has the following characteristics: - A handle to this node is inserted on all tasks. - It cannot be deleted. - It is created by the root name server at boot time. - Its ACLs are initialized in such a way that only trusted tasks can add or delete outgoing links. ø Alias nodes Alias nodes are used to reshape the name space. They provide a way to jump from one portion of the name space to another portion of the name space. To accomplish this, an alias node contains a reference to a node and a path. The node that the alias refers to must exist. When an alias is found during the name (for example path) resolution process, then the resolution process jumps to the node referenced by the alias and resolves the path stored in the alias before continuing with the resolution of the rest of the original path. ø Leaf nodes A leaf node does not have any outgoing links, that is it is the end of a name space path. A leaf node may or may not contain a send right, which can be given to a requesting task by the name server. If there is no send right, the leaf is just a placeholder for arbitrary information. If the leaf contains a send right, this points to a service provider associated with this leaf. The send right to this service provider allows the requesting task to communicate with the object or resource represented by this leaf. On the other hand, this service provider might also be another name server. This is the mechanism used to allow the name space to span multiple name servers (see the dotted line in Figure 3). The type of a node is determined at creation time and cannot be changed later on. Directories and aliases have the node type NS_NODE_TYPE_DIRECTORY and NS_NODE_TYPE_ALIAS, respectively. Leafs, on the other hand, can have the generic type NS_NODE_TYPE_LEAF, or they can have a user-defined type. Each node has a reference count. The reference count is incremented whenever a new reference to the node is established. When the reference count drops to zero, the node is deleted. Anonymous Nodes A node which has no incoming links is called an anonymous node, that is, it cannot be reached from the root directory. A task can create such an anonymous node in order to build a private name space, which is administered by the root name server. From such node an anonymous subgraph can be created, which is not part of the global name space and is therefore not known publicly. The anonymous directory can be shared by other tasks by having the task that created it provide a send right to the anonymous directory port to other tasks. Anonymous nodes and graphs can be used by peer processes as a means of interprocess communication. Paths and Name Resolution The concatenation of one or more link names is called a path. Paths are used to traverse the name space. In order to get a node handle, the requesting task has to provide: ø A handle to a starting node ø A path Given a starting node and a path, a simple, recursive algorithm returns the last node as a result of this name resolution algorithm. Accessing the Name Space Service providers need to modify the name space by means of an API in order to advertise services or to update system information. Therefore, to accomplish this task, a rich set of functions is provided by the root name server (for example, creating nodes/links as well as performing path resolution). 3.0 Chapter 3. System Services The system services play a unique role in the OS/2 Warp Connect (PowerPC Edition) environment. They are not a part of the microkernel, nor are they part of the OS/2 Server. The system services are effectively neutral services that are utilized by the other components of the operating system. The advantage of this architecture means that the OS/2 server could be replaced, or additional servers could be added to the system, without having to recode the information that is part of the system services. 3.1 Device Support 3.2 Event and Window Services 3.3 File Services 3.4 Pipe Services 3.1 File Service Client The File Services Client interfaces part of the File Services framework is the task which originates the file system request. An application submits a file system request (using native OS/2 calls), which gets translated into a file system server request. The LIBFS library, which is part of the File Services framework, then sends this request to the File Services Server. 3.2 Event and Window Services Event and Window Services (EWS) is the OS/2 Warp Connect (PowerPC Edition) mechanism for sharing the console device among applications. EWS handles screen groups, sessions and events. A session is a collection of one or more tasks (or processes in OS/2). A session owns an input queue for keyboard and mouse input, and it owns a video buffer. A session may have child sessions. Sessions maintain the state necessary to share console resources. A session may be active or inactive. Only active sessions can receive input events and be switched to the foreground. A screen group is a session which controls the state of a physical video device, keyboard and mouse (or any other locator). The events handled by EWS are essentially keyboard, mouse and pen events. Subtopics: 3.2.1 Screen Group and Session Management 3.2.2 Event Services 3.2.1 Screen Group and Session Management The EWS is called to create and destroy sessions and screen groups. The EWS maintains the session states and session interrelationships. The latter being parent/child, independent/dependent, bound/unbound, foreground/background and selectable/unselectable. The EWS provides support for exclusive sessions such as Hard Error and Popups. The EWS provides for switching screen groups, by notifying the screen groups being switched in an out of the foreground. The EWS notifies screen group owners, session owners and session watchers of session management events. The EWS allows programs to register as session watchers. As such, they will be notified about session management events. An example of a session watcher, is the OS/2 tasklist. Subtopics: 3.2.1.1 Session Manager 3.2.1.2 Sessions 3.2.1.3 Shutdown Services 3.2.1.1 Session Manager The Session Manager component is responsible for: 1. Maintaining the list of active sessions 2. Maintaining the z order of screen groups The z-order determines the layering of windows on the screen. 3. Notifying session watchers (tasklist) about session changes (creation, deletion, switch and title change) 4. Providing the session management API The session manager receives all its requests as microkernel interprocess communication messages generated from the session management API of OS/2 Warp Connect (PowerPC Edition). The session manager deals with three types of requests: 1. Popup display requests 2. Hard error display requests 3. All other requests The session manager maintains internal queues to hold the requests. Popup and Hard error requests are served before the session switching requests. 3.2.1.2 Sessions A session has a session owner, it has a video resource and it has an input queue for receiving keyboard and locator (mouse) input. Session owners in OS/2 Warp Connect (PowerPC Edition) are the OS/2 Server and the Multiple Virtual Machines component. A session owner receives a notification when a session terminates. The session owner is responsible for maintaining a list of the processes belonging to the session, and for terminating them. Sessions may be related to other sessions in parent/child relationships. Children may be bound to their parents. Selecting a session with a bound child, results in the child session being brought to the foreground instead of the parent. 3.2.1.3 Shutdown Services On a normal shutdown, EWS is called twice by the OS/2 Server. The first time it is called, EWS is requested to send a message to all screen groups and sessions, that the system is about to shutdown. This allows the involved session owners and applications to terminate normally. They may also cancel the shutdown. If none of the session owners request cancellation of the shutdown, the OS/2 Server will call event and window services a second time, and this time EWS will notify the screen groups and sessions that the shutdown is imminent. 3.2.2 Event Services The primary responsibility of the event services component of event and window services is to facilitate high-level sharing of console input. It runs as a thread of the event and window services task, reading messages posted by the micokernel to the event and window services input port. The messages received, are basically keyboard and mouse messages. However, other sources may also send messages to the input port. An example could be a pen server sending pen-created input formatted as keyboard messages, so the event services component would not know the true source of the messages. The primary job of the event services component is to translate the input events (keyboard, mouse, pen, etc.) into a common event packet, maintain shift state and pointer position, and route the message to the current input queue. In OS/2 Warp (Intel), this was done in the keyboard and mouse device drivers and in the PMWIN.DLL. The event services component of event and window services provides a common location to place all input handling. Subtopics: 3.2.2.1 Input Port Messages 3.2.2.2 Keyboard Translation 3.2.2.3 Locator Conversion And Pointer Painting 3.2.2.4 Keyboard Special Needs 3.2.2.1 Input Port Messages Five types of messages are allowed on the input port of the event services. These messages can come from the console device driver, from another device driver simulating a console device driver, or from a program simulating keyboard or mouse input. The five message types allowed, are: 1. Keyboard scancode This is the basic keyboard event as received from the console device driver. It consists of a packet containing a timestamp and a single byte of type 1 (AT enhanced) scancode. 2. Locator record This is the basic mouse event as received from the console device driver. It consists of a packet containing a timestamp, mouse button action, and position information. 3. Control The control event message is used by device drivers to send status change requests to event services. A control event message indicates a state change in the physical device, and requires that event services update its local state. 4. Multi-event The multi-event message is designed to allow a programmable interface to all of the above mentioned events. In addition, the multi-event allows input of unicode characters, virtual keys and PM scan codes. 5. Notification Notification events are sent to event services from other threads within event and window services. These are not meaningful if sent from any other place. Notifications such as session termination are sent this way. Logical Devices: Input events can come from either real devices or simulated devices, such as a pen device, or the special needs component of event and window services (see "Keyboard Special Needs" in topic 3.2.2.4). When the data comes from a simulated device, it is necessary to understand how the state of the real device affects the simulated events. Event services define the logical devices as a means of specifying these relationships. Each session has three logical console devices defined. These can be used to maintain separate settings, such as shift, for the various logical devices. This is mostly useful for a program wishing to simulate keyboard and mouse events without changing the state of the real shift and button states. The logical devices are: ø Device 0 This defines the real device. Any changes made to this device are affected by the state of the real device. ø Device 1 This defines a long term logical device. Users of this device should be careful to complete a set of actions. For instance, any keys which are pressed should be released. ø Device 2 This defines a transient logical device. Users of this device should include a EV_RESET control at the start of each record, which sets the state to match the physical device and a known shift state. Multi Event Input: Events from real keyboard and locator devices tend to consist of a single action. Simulated events are often more complicated, and consist of a series of events which must be synchronized. For instance the simulated event may consist of a mouse move, a button down and a series of keystrokes. Multi-events consist of a header followed by a series of two byte values which are interpreted sequentially. Some control values (such as the scan code input) represent a single event. Other control values (such as unicode character) contain a length where many following values are data values. The following types of events can be sent using the multi-event interface: ø Unicode Characters Unicode characters are sent with a control value which gives the count of characters, followed by a string of unicode characters. The characters are translated to complete input event packets and sent to the application as if they where entered from the keyboard. ø Codepage Characters Characters in the current keyboard codepage can be sent with a control value containing a count, followed by a string of characters. Each character is contained in a two byte field. The characters are translated to complete input event packets and sent to the application as if they where entered from the keyboard. ø Virtual keys and Deadkeys Virtual keys and Deadkeys are sent using the two byte VK_ or DK_ value as a single event. This sends a make/break of the key and has no permanent effect on the shift state. The resulting virtual or deadkey is translated and sent to the application as if entered from the keyboard. ø PM Scancodes PM translated scan codes are sent by OR-ing the scancode with the desired make/break code. It is sent as a single event value. Four make/break codes are defined: EV_SCAN, EV_SCANDOWN, EV_SCANUP and EV_REPEAT. The scancode is sent through keyboard translation and to the application as if entered from the keyboard. ø Type 1 Scancodes These are the native scancodes of the PC/AT keyboard, with additional support for the enhanced keyboard. This is the scancode sent by the keyboard. It consists of a single byte, where the highorder bit is the break indicator. A scancode of 0XE0 indicates that the next byte is an extended scancode. The scancode is sent through keyboard translation and to the application as if entered from the keyboard. ø Locator Buttons The buttons are normally associated with the mouse, although devices like pen, tablet and trackball are also supported. Button events are sent as a single event value, indicating the make/break status and the number of the relevant button. Event services support 32 buttons. The event is sent to the application as a mouse event. ø Locator Position position events are sent as a control value followed by a set of dimensions. A mouse would have two dimensions, but other devices might have more. The position can be either relative or absolute. The absolute dimension must be in the coordinate space of the locator and is translated to video coordinates by the event services. Several event types are defined: EV_RELMOVE, EV_ABSMOVE, EV_RELPOS and EV_ABSPOS. These all require the number of dimensions to be specified. Two dimension version of the above mentioned event types are also defined. This is for example EV_RELMOVEXY. These events are translated and sent to the application as mouse events. If the mouse is currently being drawn on the display, it is redrawn in the current position. ø Control Events Control events come with or without data values. Control events without data consist of a single control value. Control events with data consist of a control value containing a length, followed by some data values. 3.2.2.2 Keyboard Translation Keyboard translation is done using a set of global scancode translation tables and by calling the Universal Language Support (USL) keyboard functions. Scancodes arrive as either type 1 scancodes or PM scancodes. Type 1 scancodes are translated to PM scancodes with a simple translation table. This logic also detects repeat keys. The result of this step is a PM scancode with an indicator of make/break/repeat. The ULS keyboard function is called to update the shift state, and the resulting scancode and shift state are used to generate the BIOS scancode. If the keyboard LED state is changed, the keyboard device driver is called to do the update. The ULS keyboard function is called to generate the unicode character and the virtual key. The unicode character is used to construct the codepage character. When the input is a character, the ULS keyboard untranslate function is used to translate the character to a scancode. Keyboard layouts are defined by the ULS component, and are global to all session owners (OS/2 Server and Multiple Virtual Machines Server) in OS/2 Warp Connect (PowerPC Edition). They may be changed at any time, and applications may simultaneously be using different keyboard layouts. These keyboard layouts are user definable and created using the keyboard compiler (makekb). Hotkey Processing: After a key is translated, and before it is routed to the current input queue, a check is made to see if it is a hotkey. This can be done only after shift translation is done. Then keys are matched against the hotkey table within event and window services. If the key is a hotkey, the associated port is notified. Hotkeys may be global (for instance CTL-ALT-DELETE) or session (for instance CTL-BREAK). Event and window services support an API call to set hotkeys. 3.2.2.3 Locator Conversion And Pointer Painting The coordinates of the locator must be converted to absolute coordinates in the coordinate space of the current video mode. The locator coordinate mapping logic can be replaced with a user function. This function is an entrypoint in a shared library, and is called with the current locator position, coordinate mapping information and the locator event. In OS/2 Warp (Intel), the mouse pointer is painted as part of the mouse interrupt. In OS/2 Warp Connect (PowerPC Edition), the locator pointer is painted when the event is processed by event services. The actual painting is done by sending a message to the session owner, and the session owner's paint function (for instance PM if the session owner is the OS/2 Server) will do the actual painting. A paint request is only sent when it is necessary. The decision of when to paint is based on the time since the last painting and distance moved. Event and window services allow each session to specify an interest rectangle. This rectangle is set up by the session owner, and is used to allow suppression of certain locator events, either inside or outside of the rectangle. 3.2.2.4 Keyboard Special Needs Some people have difficulties using the traditional keyboard and mouse so that they need special accomodations. The event and window services keyboard special needs component provides these accomodations. This support is modeled closely on the industry standard AcessDOS from the Trace Center at the University of Wisconsin. The functional names used in this section are the names used in AccessDOS. The following functions are supported: ø StickyKeys Allows the user to press each key of a multiple key operation separately. ø RepeatKeys Sets the keyboard repeat rate to a slow rate, or turns it off all together. ø SlowKeys Sets the sensitivity of the keyboard by not accepting a key until it is held down for a certain period of time. ø BounceKeys Prevents a key which is quickly repressed from being seen as a double press on the key. ø ToggleKeys Use a sound to indicate that a toggle key has been pressed. ø MouseKeys Use the keys on the numeric keypad to simulate a mouse. ø SerialKeys Use an external device attached to the serial port (or other character device) to act as an additional keyboard. 3.3.1 File Service Client The File Services Client interfaces part of the File Services framework is the task which originates the file system request. An application submits a file system request (using native OS/2 calls), which gets translated into a file system server request. The LIBFS library, which is part of the File Services framework, then sends this request to the File Services Server. 3.3.2 File Services Server The File Services Server part of the File Services framework includes the Logical File System, the File Services Pager and the Physical File System. This framework is designed to allow many different Physical File Systems (from within IBM or from other vendors) to be plugged in with minimal effort. In the first release FAT, HPFS and a CD-ROM Physical File System are supported. IBM plans to encourage other vendors to port their Physical File Systems to this framework. Subtopics: 3.3.2.1 Logical File System 3.3.2.2 File Services Pager 3.3.2.3 Physical File System 3.3.3 Thread and Port Model The components of the File Services are executed on a thread and port model that is provided by the File Services framework. Ports are used in the communication between the File Services Server, the File Services Client, the device drivers and the microkernel. Threads are used to multi-thread the activity of the File Services Server. 3.3.4 File Services Pager The File Services Pager is one of the external pagers for OS/2 Warp Connect (PowerPC Edition). It is the only component in the File Services Server that is communicating with the hardware through the Device Services The File Services Pager consists of components to control the usage of memory, to handle page-in and page-out requests and to interface with the other parts of the File Services Server The File Services Pager and its related components have the following key responsibilities: ø Handling of all paging requests returns from the microkernel for the memory objects that it owns. ø Handling of all input/output required to process a page-in or page-out request for the memory objects that it owns. ø Support mapping of memory objects into the address space of the File Services Server and the address space of the File Services Client. 3.3.5 Physical File System (PFS) The File Services Framework is designed to allow many different Physical File Systems to be plugged in with minimal effort. The Physical File System is a service provider to the File Services Framework. Each Physical File System must include a set of Physical File System utilities to support CHKDSK, FORMAT, RECOVER and SYS. If the Physical File System contains files needed to boot the system, it will need to have a Boot-PFS included. Physical File Systems included in OS/2 Warp Connect (PowerPC Edition) are: FAT, HPFS and CD-ROM. Subtopics: 3.3.5.1 Physical File System Interfaces 3.3.5.2 File System Utilities 3.3.5.3 FAT, HPFS and CD-ROM Physical File Systems 3.3.6 Volume Manager The intent of the Volume Manager is to encapsulate the details associated with the identification and accessing of the different storage volumes available to the system. It simplifies the requirements on the File Services Server by isolating it from variations in partition schemes and by providing a repository for pertinent partition/volume information. It additionally can serve as a centralized component for general volume management function, ranging from the mundane task of obtaining the data associated with the separate volumes to more sophisticated volume management features such as volume spanning, striping, mirroring, etc. The first implementation of the Logical Volume Manager is called Basic Volume Manager (BVM) and is implemented to meet the initial requirements, with consideration given to future expansion. The functions that are provided by the Basic Volume Manager are the following: ø Upon invocation at IPL, the Basic Volume Manager spawns the volmgr server and inserts the appropriate node under the servers branch of the root name server. Subsequent invocations will fail when the presence of the volmgr node is detected. ø The Basic Volume Manager creates and maintains the volumes subtree under the root name server ø The Basic Volume Manager creates a logical device instance for all valid and recognized partitions (volumes). ø The Basic Volume Manager provides an interface that allows external parties to query and/or notify the Basic Volume Manager of changes in the status of any volume subtree entries, and it updates those entries appropriately. ø The Basic Volume Manager monitors the root name server devices subtree and the logical device instances created for the tracked volumes and performs the appropriate updates on the root name server volumes subtree as devices/partitions/volumes are changed. 3.4 Pipe Services The pipe server is a personality neutral server that provides OS/2 Warp Connect (PowerPC Edition) applications with the abstractions required for interprocess communication through the use of pipes. The IBM microkernel's message passing architecture through one way message passing and Remote Procedure Call (RPC), provides the basis for the pipe server, with some additional capabilities provided to the pipe server clients, for example, named communications channels, reading the pipe data in a user specified format, queueing up for a pipe till it becomes available for use, remote pipe support, among others. The purpose of the pipe server is to provide a basic set of interfaces for creating and using pipes, without attempting to be specific to any particular operating system's implementation of pipes. The API set is therefore generic, and any further specific functionality required by OS/2 Warp Connect (PowerPC Edition) will have to be implemented in an emulation library. The OS/2 Warp Connect (PowerPC Edition) emulation library provides the OS/2 pipe APIs with specific functionality such as: ø Peeking into a pipe to look at the data in it, without removing the data from it. ø Associating a semaphore with a pipe, to synchronize read and write operations on a pipe. Pipe Server and the Name Space Upon initialization, the pipe server will register itself with the root name server which will provide a service port, that can be used by any client that needs to communicate with the pipe server. When an application wants to create a pipe, the pipe server registers this pipe in the root name server under the pipe server's directory on behalf of the requesting application. Thus, the name space tree regarding pipes is created and controlled by the pipe server. The name space for the pipes consists of the pipe tree which has an entry for each named pipe in the system. As pipes can also be used as a means of communications between remote machines, the pipe server will also register remote pipe names under the name space for the corresponding redirectors (like IBM LAN, Novell). This allows the pipe server to determine which redirector to request services from, for an opening of a specific pipe on a remote server. In order to keep an updated list of network redirectors, the pipe server requests the root name server for notifications about changes to the tree of redirectors in the name space. 4.0 Chapter 4. OS/2 Functions This chapter describes the basic OS/2 functions known from OS/2 Warp (Intel). They are "OS/2 Server" in topic 4.1, "The MVM Environment" in topic 4.2, "Graphics Subsystem" in topic 4.3, and "Printing Services" in topic 4.5. There is also a section describing the systems management functions of OS/2 Warp Connect (PowerPC Edition), "System Management." in topic 4.6. Subtopics: 4.1 OS/2 Server 4.2 The MVM Environment 4.3 Graphics Subsystem 4.4 Graphics Subsystem Summary 4.5 Printing Services 4.6 System Management. 4.1 OS/2 Server The OS2 Server is designed to provide the OS/2 Warp 3.0 API (the API calls with prefix DOS) on behalf of OS/2 Warp Connect (PowerPC Edition). It is assumed that the reader is familiar with the basic functionality of the OS/2 Warp (Intel) kernel, also called the OS/2 Control Program. For more information about the OS/2 Control Program, see OS/2 Version 2.0. Volume 1: Control Program, GG24-3730 . Subtopics: 4.1.1 OS/2 Server Architecture 4.1.2 Configuration 4.1.3 Components Of The OS/2 Server 4.1.4 Loader 4.1.5 Startup 4.1.6 Shutdown 4.1.1 OS/2 Server Architecture The OS/2 Server architecture is based on a client/server model that makes use of microkernel interprocess communication (IPC). The client side of the model is OS/2 Warp 3.0 applications. The applications communicate through the API to a set of DLLs, which are responsible for providing the APIs, either directly or by requesting service from the server side of the model. Figure 5 depicts the base API calls implementation. ________________________________________________________________________ | | | | | | | | | | | | | | | |________________________________________________________________________| Figure 5. Base API Calls Implementation Subtopics: 4.1.1.1 Client Side 4.1.1.2 Server Side 4.1.1.1 Client Side This section looks at the general aspects relating to the client side of the client/server model mentioned earlier. When we describe the different components of the OS/2 Server in more detail, we see that there might be client side issues to be discussed. The client side is a collection of DLLs and libraries, bound to OS/2 user processes. The DLLs are as follows: ø DOSCALLS.DLL This DLL contains the most commonly used API calls with prefix DOS. ø QUECALLS.DLL The entry points for the Queue related API calls are found in this DLL. ø LIBMK.DLL This DLL contains library routines for the microkernel system calls. ø LIBCXPG.DLL and LIBCMXPG.DLL These libraries contain the common ANSI C runtime routines. The system calls in LIBMK.DLL are used to implement some of the functions in LIBCXPG.DLL and LIBCMXPG.DLL. ø FSCALLS.DLL This library contains the API calls to the file services in OS/2 Warp Connect (PowerPC Edition), implemented as a shared service. The base API calls to the OS/2 Server are resolved by the loader into entrypoints in the DLLs on the client side. Some of the API calls are handled entirely within the client side DLL, while other calls result in messages being sent to the microkernel. The majority of calls are made as remote procedure calls to components of the OS/2 Server. 4.1.1.2 Server Side This section looks at the general aspects relating to the server side of the client/server model mentioned earlier. The OS/2 Server consists of a single multithreaded task (task is the microkernel term equivalent of an OS/2 process). For performance reasons, the OS/2 Server is multithreaded. The following are the main threads: ø One initial thread Which performs the initialization and spawns other threads. ø Multiple message threads These threads read client requests, in the form of IPC messages from a microkernel port set. When finished with a request, a reply is sent back to the request originator. ø One exception thread Which reads exceptions raised by the microkernel. ø Multiple pager threads Which handle page faults. ø One semaphore timeout thread Which implements semaphore timeout functionality. ø One timer timeout thread Which implements timer timeout functionality. ø One control port read message thread Used to spawn other tasks from external servers. ________________________________________________________________________ | | | | | | | | | | | | | | | |________________________________________________________________________| Figure 6. Main Interfaces of the OS/2 Server Figure 6 shows the microkernel ports used by the OS/2 Server in order to interface with other components of OS/2 Warp Connect (PowerPC Edition). "Inter Process Communication (IPC)" in topic 2.1.3 describes the interprocess communication supported by the microkernel and used by the components of OS/2 Warp Connect (PowerPC Edition). Whenever a task (or OS/2 process) or thread is created, it is associated with a microkernel port. These ports are not depicted in the figure. ø Control Port The OS/2 Server receives messages on this port from other servers in the system wanting to run OS/2 programs. ø Server Port Set The OS/2 Server has read rights to this port set, and uses it to read requests from user processes. ø External Server Ports Used by the OS/2 Server to send messages to external servers, such as name services, or File Services. ø Device Control Port Privileged microkernel port used to access devices. ø Timeout Ports The OS/2 Server receives messages on these ports from the microkernel, when requested timers are expired. ø Host Ports These ports are used to inquire and set the system clock, and to alter scheduling policies on behalf of threads. ø Exception Port Set A port set where the OS/2 Server receives exception messages from the microkernel on behalf of any user thread. 4.1.2 Configuration The OS/2 Warp Connect (PowerPC Edition) environment defines a system name space, which contains persistent object information for all the OS/2 Warp Connect (PowerPC Edition) environment including configuration information for the OS/2 Server. In OS/2 Warp (Intel), configuration information is found in the CONFIG.SYS file. No API is present in OS/2 Warp (Intel), with the purpose of updating the CONFIG.SYS file. All updates are made directly to the CONFIG.SYS file. This is common practice, when installing application programs. It makes the boot process of OS/2 Warp (Intel) vulnerable, because a successful boot is dependent on the contents of CONFIG.SYS. The CONFIG.SYS file still needs to be maintained in OS/2 Warp Connect (PowerPC Edition) for compatibility with applications that use the file directly. OS/2 Warp Connect (PowerPC Edition) however, only uses the following statements during the boot process: SET, RUN and RUNSERVER. The SET and RUN statements, are the ones we know from OS/2 Warp (Intel), while RUNSERVER is new in OS/2 Warp Connect (PowerPC Edition). RUNSERVER starts only privileged services. All RUN statements will take place after all the RUNSERVER statements. The RUNSERVER command takes the following parameters: RUNSERVER= {-arg "arguments"} {-lookfor } {-timeout } The RUNSERVER statement synchronizes the startup of a server program based on the parameters provided. By default the RUNSERVER will wait until the program terminates. If the option -lookfor is specified with a name, the RUNSERVER will wait until the name has been created in the system name space. If some maximum time has been specified with the -timeout option, the RUNSERVER will wait this maximum amount of time before returning. If both -lookfor and -timeout are given, the RUNSERVER will return as soon as one of the options is satisfied, or a completion notification is received (the program has terminated). The following RUNSERVER statement shows how the event and window services may be started: RUNSERVER=C:\os2\ews.exe -LOOKFOR servers\SessionClient -TIMEOUT 20 ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3 Components Of The OS/2 Server This section looks at the different components of the OS/2 Server. We start with the description of handle management, because it is common to many of the components we describe later in the section. Subtopics: 4.1.3.1 Handle Management 4.1.3.2 Session Support 4.1.3.3 Tasking 4.1.3.4 Memory Management 4.1.3.5 Semaphores 4.1.3.6 File I/O Support 4.1.3.7 Pipes 4.1.3.8 Queues 4.1.3.9 Timer Management 4.1.3.10 Exception Handling 4.1.3.11 Message Management 4.1.3.12 Debugging Support ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.1 Handle Management The concept of a handle is well known from OS/2 Warp (Intel). After an initial API call, giving the name of a requested resource, when successful, OS/2 returns an entity known as a handle. All subsequent API calls referring to the mentioned resource, must use the handle to identify the resource to OS/2. Handle management must manage two types of handles. The handles on the client side in DOSCALLS.LIB and the handles on the OS/2 Server side. Figure 7 shows two user applications (represented by PTDA 1 and PTDA 2) and their involvement with the handle management. ________________________________________________________________________ | | | | | | | | | | | | | | | | |________________________________________________________________________| Figure 7. Handle Management Examples ø Client side handle management The handle management on the client side maps the OS/2 handle to a microkernel port and a handle type. The OS/2 handle is actually an index into a table. There is one handle table per process, and handles can be inherited by child processes. The handle type is used to identify the component serving the object referenced by the handle. This component will either be routines residing entirely on the client side, or it will be a component of the OS/2 Server or it may be a system service. In Figure 7, we see that the client part of the application requesting file services (represented by PTDA 1), communicates directly with File Services. The client side of the other application (represented by PTDA 2), points to the handle table on the server side, and eventually winds up communicating with the pipe server. Notice also that the linked list based on the microkernel port, also contains a timer data structure, indicating that application 2 also has a pending timer request. The semaphore and the queue component of the OS/2 Server have their own handle management. ø Server side handle management The handles on the OS/2 Server side are microkernel ports. There is one global handle table on the server side, which is an array of pointers. The microkernel ports are hashed to get their position in the table. Each pointer points to a linked list of handle table entries, with the last pointer being null. Each handle entry is part of the data structure associated with the component being managed, so the address of a component's data structure can be found by getting the address of its table entry via the microkernel port. The handles managed by the handle management component, and how they participate on the client and/or server side are: ø File - only client side interaction ø Device - only client side interaction ø Pipe - both client and server interaction ø Timer - only server side interaction ø Process - only server side interaction ø Thread - only server side interaction ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.2 Session Support Refer to "Event and Window Services" in topic 3.2, to get a definition of a session. The session component of the OS/2 Server provides the API calls which implement the functionality of the OS/2 Warp (Intel) session management. In OS/2 Warp Connect (PowerPC Edition), session management is the responsibility of the event and window services. When the OS/2 Server receives a session request, it will work in conjunction with the event and window services to fulfill the request. Event and window services will be started by the OS/2 Server during startup. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.3 Tasking The tasking component of the OS/2 Server is responsible for the management of OS/2 processes and threads. This include process and thread creation, control and termination. The tasking component is also responsible for providing process and thread information and for handling thread synchronization through thread suspension or allowing threads to wait on other threads. Finally, the tasking component is responsible for implementing the process and thread API as we know it from OS/2 Warp (Intel). The tasking component interacts with other OS/2 Server components including memory management, the loader, and the semaphore system. Its main interface is the microkernel, because it directly uses the microkernel task and thread support, see "Tasks and Threads" in topic 2.1.4. The tasking component of the OS/2 Server has the following key responsibilities: ø Process creation and thread creation ø Maintain information about process and thread specific data ø Control and provide information about current processes and threads ø Process and thread termination and cleanup Process and Thread Creation: An OS/2 process maps directly to a microkernel task. A process is started by a DosExecPgm call to the tasking component. A control block called the Per Task Data Area (PTDA) is created on behalf of the process. An initial thread is created on the behalf of the process. An OS/2 thread maps directly to a microkernel thread. A thread is created by the DosCreateThread call to the tasking component. A thread information block (TIB) structure is initialized and associated with the thread. Process and Thread Information Maintenance: Each process has a PTDA associated with it. The PTDA is kept in the address space of the OS/2 Server. The main content of the PTDA is the OS/2 handle of the process, the associated microkernel port and the address of the TIB for the initial thread. As each new thread is created, a TIB is associated with it. The TIB is kept in the address space of the OS/2 Server and it contains port information, priority information, thread stack information, and the rest of the machine state information. Process and Thread Query and Control: The DosGetInfoBlocks API call provides information to an application about its process and its current thread. The DosSetPriority call enables applications to alter the priorities of their threads. The tasking component supports synchronization between a process and its child processes. It supports synchronization between threads, so that threads may wait on other threads, threads may suspend other threads and threads may kill other threads. Also the DosEnterCritSec/DosExitCritSec calls are supported. Process and Thread Termination and Cleanup: Process and thread termination is managed by the tasking component of the OS/2 Server. When the initial thread of a process is terminated, the process is terminated. When a thread terminates, its TIB is released. When a process terminates, its PTDA is released. A process may have registered exit processing. In this case the tasking component is responsible for managing the exit list processing. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.4 Memory Management The memory management component of the OS/2 Server has the following key responsibilities: ø Manage private/shared memory areas for OS/2 applications ø Manage page faults for guard pages and executable objects ø Manage the growth and shrinkage of the paging space used by the microkernel's default pager. ø Implement memory related OS/2 API The memory management component of the OS/2 Server uses the microkernel virtual memory management functions to implement the OS/2 memory management semantics. OS/2 applications expect certain behavior with regard to memory allocation and shared memory, such as all shared memory must be loaded at the same virtual address in all participating processes. The memory manager component takes advantage of the microkernel's External Memory Management (EMM) support to free it from page management, and instead let it focus on memory object management. See "External Memory Managers" in topic 2.2.3 for more information on the EMM. The EMM will direct a page fault to the appropriate page fault handler for that particular page. The page fault handler would be the default pager, the OS/2 loader or the File Services, depending on the context of the faulted page. Private and Shared Memory for OS/2 Applications: The memory manager component uses arenas to manage private and shared memory for OS/2 processes. An arena is a circular-linked list that is used to keep track of memory allocation in the address space of an OS/2 process. The information contained in the arenas is just what is needed to extend the microkernel memory semantics to OS/2. The virtual address space supported by OS/2 is a 4GB linear address space with its layout (see Figure 8). ________________________________________________________________________ | | | | | | | | | | | | | | | | |________________________________________________________________________| Figure 8. Virtual Address Space Layout An OS/2 process may request private memory either by using the DosAllocMem call or by using the C runtime support. The C runtime support of malloc, realloc, etc. is not using the memory management component, but calls the appropriate microkernel functions directly. The Global Shared Memory (GSM) contains memory that is immediately accessible to all processes in the system. The user processes will only have read/execute access to the GSM, while servers (for example the loader) may have write access. The Global Coerced Memory (GCM) is used where there is need for more restricted access to memory objects. In the GCM area, memory is allocated in blocks, where each block may have different access attributes for each process with addressability to the block. Page Faults for Guard Pages and Executable Objects: The manager of page faults on behalf of the memory manager is called the OS/2 pager. The OS/2 pager is responsible for managing page faults for pages that contain compressed data (for example Presentation Manager resources) and stack guard page faults. Compressed data page faults are handled by invoking the loader to load the appropriate information from the executable file and decompressing it. Stack guard page faults are handled by simply allocating more stack space via the exception handling component, see "Exception Handling" in topic 4.1.3.10. All other page faults are handled by the default pager or File Services. Growth and Shrinkage of Paging Space: The growth and shrinkage of the default pager's paging space is the responsibility of the OS/2 Server. It does so by issuing appropriate API calls (DPAGER_XX...) to the default pager. The OS/2 Server must: ø Monitor the utilization of the paging space via DPAGER_Set_Threshold. The default pager will send a notification message to the OS/2 Server when the threshold is reached. ø Allocate additional space to the paging space when the utilization of the paging space has reached 80%. This is done by the call DPAGER_Add_Space. ø Remove excess space from the paging space when the utilization of the paging space drops below 50%. This is done by a call to DPAGER_Remove_Space. ø Log errors to the system log Implement Memory Related OS/2 API: The memory manager component of the OS/2 Server handles all the memory related API calls, with the exception of the Memory Suballocation Package (MSP). The MSP is implemented solely in the DOSCALLS.DLL client library. The memory manager component uses the microkernel virtual memory manager functions in order to implement the memory related API. The calls for memory allocation need to be identified to the microkernel. This is done by sending the task port of the OS/2 process doing the API call, with the call to the microkernel. The process of identifying the originator of the API call and manipulating the message parameters is the job of the Message Interface Generator code. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.5 Semaphores The semaphore component of OS/2 Warp Connect (PowerPC Edition) is ported directly from OS/2 Warp (Intel). The only alteration necessary, is to the DOSCALLS.DLL, which now uses microkernel interprocess communication to communicate with the semaphore component of the OS/2 Server. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.6 File I/O Support The OS2 Server is not involved with the file I/O requests made by the applications. The file I/O API calls in DOSCALLS.DLL are converted to the FS_XX... API calls of File Services. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.6 File I/O Support The OS2 Server is not involved with the file I/O requests made by the applications. The file I/O API calls in DOSCALLS.DLL are converted to the FS_XX... API calls of File Services. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.7 Pipes The main effort regarding pipe creation and maintenance is with the Pipe Server running as a system service. An application calls a pipe API residing in the DOSCALLS.DLL. Parameters are validated within the DLL. If OK, the request is shipped to the pipe server and handled there. Upon completion of the request, a process handle on the client side is generated or updated (if it already exists). See "Handle Management" in topic 4.1.3.1 for an explanation of handle management. If the API request involves a semaphore, or the pipe content is of type message, the OS/2 Server participates in the pipe management process, otherwise the pipe is managed solely by the pipe server. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.8 Queues The queues component of OS/2 Warp Connect (PowerPC Edition) is just ported from OS/2 Warp (Intel), with the necessary alterations to the QUECALLS.DLL to use microkernel interprocess communication to the queue component of the OS/2 Server. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.9 Timer Management The timer management component of the OS/2 Server is responsible for implementing the API calls DosSleep, DosGetTime, DosSetTime and the start and stop timer API calls. The DosSleep call and the DosGetTime call are implemented by directly calling the similar function in the microkernel from the DOSCALLS.DLL. The DosSetTime function is handled differently, because it must perform a privileged operation on the microkernel. In this case the OS/2 Server is called via the RPC interface, and the OS/2 Server does the necessary call to the microkernel, through the Host port in Figure 6 in topic 4.1.1.2. The timer calls are handled as in OS/2 Warp (Intel), apart from the fact that the timeout notifications are handled by the microkernel by sending messages to the timeout port of the OS/2 Server. The notifications are sent as a result of preceding set alarm calls made by the OS/2 Server to the microkernel. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.10 Exception Handling The exception handling component of the OS/2 Server is responsible for emulating all the exception related API calls and also for handling exceptions raised by the microkernel. Exceptions that arrive at the OS/2 Server can have two distinct origins: ø Microkernel Raised Exceptions These are the actual microkernel exceptions that the OS/2 Server receives by a thread of the OS/2 Server called the system exception server. Examples of these exceptions are all the hardware generated exceptions, such as memory access violations, divide by zero, etc. The OS/2 system exception server receives these exceptions, translates them into OS/2 style exceptions and calls the appropriate routines to handle them. One special exception handled by the system exception server, is the guard page fault exception (see "Page Faults for Guard Pages and Executable Objects" in topic 4.1.3.4). The system exception server simply allocates more stack memory on behalf of the failing thread. ø Client Side Raised Exceptions These exceptions are not exceptions from the microkernel point of view, but are actually OS/2 exceptions resulting from DOSXXX API calls on the client side. These API call generated exceptions are handle by a component of the OS/2 Server called the application exception server. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.11 Message Management The message management component of the OS/2 Server enables application programs access to messages kept in separate files outside of the applications. This component is ported directly from OS/2 Warp (Intel) The utility MKMSGF is ported and also the linker must support the binding of the message support segment created by the MKMSGF utility. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.3.12 Debugging Support The debug component of the OS/2 Server supports two interfaces to its system services. These interfaces are the DosDebug API known from OS/2 Warp (Intel), and the new Debug Probe. Debug support enabled by the debug probe is the capability to follow the flow of an application request across all server calls and into the microkernel. The debug probe provides an interface to the OS/2 Server for debuggers which require information specific to the OS/2 Server. The primary interface is a set of request/reply messages required to debug or trace debuggee programs. The API calls available to debuggers are similar to the DosDebug API calls. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.4 Loader All tasks (or OS/2 processes) in the system after the initial tasks loaded by the bootstrap loader (see "Bootloader" in topic 4.1.5.1) are loaded by a single loader, the OS/2 server loader, in cooperation with the OS/2 Server memory management component. The OS/2 Warp (Intel) semantics of global shared memory (text and data) at the same virtual address in every task's address spaces is preserved. This is true for all tasks including virtual DOS machines, device drivers and system services. Some of the design goals for the OS/2 loader are: ø Use a single library binary and a single virtual copy of libraries loaded by both OS/2 processes and system services. ø Have a single loader in the system at any point in time. Preferably, this loader should have been implemented as a system service. ø Provide global shared memory services for those tasks (and OS/2 processes) that require them. The loader is responsible for the loading of code and data from executable modules on disk on behalf of an OS/2 application. The loader supports 32-bit little endian modules in the Executable and Linking Format (ELF) format. See AT&T UNIX System V Release 4 Programmer's Guide: ANSI C and Programming Support Tools for more information about ELF. The responsibilities of the loader can be summarized as follows: ø Loading of OS/2 executable and OS/2 dynamic link libraries and system service libraries at OS/2 process creation time at the request of the tasking component of the OS/2 Server. ø Unloading the OS/2 executable and OS/2 dynamic link libraries and system service libraries at OS/2 process termination time at the request of the tasking component of the OS/2 Server. ø Loading and unloading of OS/2 dynamic link libraries and system service libraries as requested by the OS/2 application. ø Cooperating with the tasking component of the OS/2 Server to supply per process and per system library initialization and termination. ø Cooperating with the debug component of the OS/2 Server to support the DosDebug API. ø Providing access to resources as requested by the OS/2 application. ø Providing the API for loading, unloading and querying dynamic link libraries. ø Allowing OS/2 applications access to functionality exported by system services. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.5 Startup This section describes the OS/2 Warp Connect (PowerPC Edition) boot sequence resulting in the microkernel and the OS/2 Server running. The OS/2 Server subsequently starts up the rest of the OS/2 services including the user interface and the Multiple Virtual Machines. Also the event and window services is started by the OS/2 Server. Subtopics: 4.1.5.1 Bootloader 4.1.5.2 The Bootstrap Task ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.5.1 Bootloader The boot process begins when the bootloader image is brought into memory by the PowerPC firmware. The image in memory contains the bootloader program, the boot device driver and the file system extensions needed to access the boot media. The device driver and the file system support in the bootloader can change depending on the installation (for example the boot device is a CDROM device and the installation target is a hard disk). The device extensions and file system extensions are dynamically linked to the bootloader to allow it to read files for each boot device. There is a distinction between the boot device and its file system extension and the paging device and its file system extension. They may be the same for a particular boot of the system, but if the boot device is a CDROM device, the paging device would be assigned to a different device. The OS/2 Warp Connect (PowerPC Edition) installation for release 1.0 requires two disk partitions, a small hidden partition required by the PowerPC firmware, and the system partition. Chapter 5, "Installation" in topic 5.0 will provide you with more information about installation requirements. The hidden partition only contains the bootloader, which is loaded and started by the firmware. The system partition contains the microkernel binaries, the base paging space, the Basic Volume Manager, the registry, all of the OS/2 services and configuration files such as BOOT.CFG and CONFIG.SYS, as well as stanza files describing the hardware. A paging file managed by the OS/2 server will also be on the system drive. The bootloader is responsible for loading programs and files into memory and creating and maintaining a data structure to be delivered to the microkernel when it is started by the bootloader. The bootloader reads the BOOT.CFG file from the system partition. BOOT.CFG is an ASCII file containing information about programs and files to be loaded into memory by the bootloader. BOOT.CFG may contain entries PN_BOOT_DEV and PN_BOOT_FS that specify the storage device and the file system to be used for reading the remainder of the files loaded by the bootloader. The entries may appear multiple times, allowing the boot information to be collected from different places. A PN_BOOT_CONFIG statement in BOOT.CFG gives the name of a configuration file that contains additional configuration information. The bootloader has a fail safe boot recovery capability in the case of bad boot information. The bootloader will use the last good copy of BOOT.CFG in this case. After the bootloader has finished its task (loading programs and files into memory), it starts the microkernel. The microkernel starts the bootstrap task. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.5.2 The Bootstrap Task The bootstrap task has all of the files loaded by the bootloader in its virtual address space. The bootstrap task knows which tasks to start via the information it obtains from the microkernel through the host_get_boot_info interface. The microkernel, on the other, hand got the information directly as a data structure from the bootloader. The bootstrap task starts the tasks as identified by the PN_FILE_NAME entries in BOOT.CFG. The bootstrap task knows if a file named in a PN_FILE_NAME is a program to be started, because a program must have at least one PN_FILE_ARG= entry. If no argument is required, the is just a null string. The order of the startup of the individual components is important. They are started in the order they appear in the BOOT.CFG file, due to dependencies on previously started components. The bootstrap task waits for a started component to register itself with the root name server and to place its service port within the root name server. The root name server itself is a special case to the bootstrap task, in that the bootstrap task waits for a message from the root name server (after having started it), containing the root name server service port. The bootstrap task provides the root name server service port to all services is starts. The bootstrap task also registers its file services port with the root name server. Services Started by the Bootstrap Task: As already mentioned, the root name server is started and its service port kept by the bootstrap task. The root name server enables name services to be present for all components started subsequently. The name space entries which need to be persistent, will not be made persistent until the registry server is started later in the boot sequence. The default pager is started with no paging space available. It registers itself with the root name server. The base paging space is allocated by the dominant personality pager initialization task (PAGRINIT), after the paging device driver and File Services are started later in the boot sequence. In release 1.0, Device Configuration Services consists of the Hardware Resource Manager (HRM), Configuration Manager and Device Manager. HRM is started first, and it uses stanza files to recognize the hardware in the system. Stanza files are ASCII text files containing descriptions of the various hardware components. Next, the Configuration Manager is started, followed by the Device Services. Device Services calls the API LDR_XX... to start the device drivers. The drivers are then placed in memory by the bootloader. The bootstrap task now starts the OS/2 initialization, the Basic Volume Manager and the File Services. It is now ready to start PAGRINIT, because the file system is available. After paging is enabled, the registry is started. Finally, the bootstrap task creates the OS/2 Server task and starts the OS/2 Server. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.6 Shutdown The intent of a shutdown is to quiesce applications and system services in preparation for rebooting or powering off the system. Therefore, programs receiving a shutdown message, should make sure that any volatile data should be saved before it terminates. A program does not need to terminate, and could in fact request that shutdown be halted. An OS/2 Server thread controls the shutdown process. Subtopics: 4.1.6.1 Shutdown Invoked by User or API 4.1.6.2 Shutdown via CTRL-ALT-DEL 4.1.6.3 Abnormal Termination of a Shared Service ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.6.1 Shutdown Invoked by User or API The user or an OS/2 application can request a shutdown of the system. This is done via a Workplace Shell desktop selection, or via the APIs WinShutdownSystem and DosShutdown. WinShutdownSystem is an orderly shutdown for OS/2 applications and system services that elect to be notified of a pending shutdown. DosShutdown simply flushes the file system cache and perform other requested actions such as system dump and reboot. WinShutdownSystem: The Workplace Shell gets the desktop shutdown request from the user and issues a WinShutdownSystem call to Presentation Manager. A Presentation Manager application may also call WinShutdownSystem. Then the Presentation Manager calls the OS/2 Server. The OS/2 shutdown thread: ø Calls event and window services to shutdown screen groups and sessions as described in "Event and Window Services" in topic 3.2. A nonzero return code makes the shutdown halt. ø Sends a shutdown message to each server that registers its service port in the \server or \device name space nodes with an attribute of ShutdownMessage=Yes. Servers or device drivers that do not have this attribute will not be informed about the shutdown. - The shutdown thread sends shutdown messages to each server followed by shutdown messages to each device driver. An attribute of ShutdownOrder={range 0-255} can be specified to control the order of notification. Servers with a value of 0 are notified first, while servers with a value of 255 are notified last. Servers with the same value have no implied ordering. - The File Services shutdown, ShutdownOrder=128, will flush any disk caches and disable further write operations, but the File Services will remain operational and able to handle page faults. - These shutdown messages are done as remote procedure calls. The shutdown thread will wait for each server to respond. In release 1.0, the number of servers requesting notification are small, and they are trusted to respond. ø Calls event and window services again to indicate that shutdown is complete or that it is cancelled. ø Returns control to the caller of WinShutdownSystem (the Workplace Shell or the Presentation Manager application) which displays a message to the user that it is safe to power off or reboot the system. DosShutdown: The DosShutdown API has been extended to allow a Software Distribution Manager like NetView/DM to initiate a file system shutdown, followed by a reboot. System dump and halt options have also been added. DosShutdown can perform the following actions: ø Send a Shutdown message to the File Services to flush buffers to disk and quiesce the File Services. The File Services will disable further write operations but will remain operational and able to handle page faults. ø Perform a system dump, reboot the system or halt the system as required. ø Control is returned to the caller which can then display a message informing the user that it is safe to turn off the power or reboot the system. If a dump, halt or reboot is requested, control is not returned if the request is successful. In order for a system dump to be taken, the location of the dump file must be specified to the microkernel by a systems management utility. The dump, halt and reboot actions are initiated through the host_reboot call to the microkernel, using the Host Control port, with RB_DUMP, RB_HALT or RB_REBOOT option specified. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.6.2 Shutdown via CTRL-ALT-DEL The shutdown thread of the OS/2 Server performs the following actions when it receives a CTRL-ALT-DEL notification: 1. Sends a message to the screen, indicating rebooting. 2. Sends a Shutdown message to the File Services to flush buffers to disk and quiesce the File Services. The File Services will disable further write operations but will remain operational and able to handle page faults. 3. Reboots the system via the host_reboot call to the microkernel, using the Host Control port. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.1.6.3 Abnormal Termination of a Shared Service In release 1.0, there is no provision for restarting a failing system service The architecture allows for a monitoring of servers through the port_death notification, so that the OS/2 Server might restart failing system services. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2 The MVM Environment OS/2 Warp Connect (PowerPC Edition) includes binary support for DOS, Windows or DPMI applications. In this, the first release, the operating system provides DOS support that is based on the OS/2 Warp (Intel) version of the product. The Multiple Virtual Machine (MVM) environment provides the following functionality to the OS/2 Warp Connect (PowerPC Edition) operation system: ø Boots a DOS emulation kernel in a Virtual DOS Machine (VDM). ø Boots a non-emulated version of DOS (for example DRDOS, Novell DOS, DOS V3.3 and above) in a Virtual Machine. In OS/2 Warp (Intel), this is referred to as a Virtual Machine Boot (VMB) . ø Runs multiple DOS applications concurrently in the system. ø Runs DOS applications fullscreen or windowed. ø Provides DOS, Windows, DPMI applications access to a common set of file systems shared with other personalities in the OS/2 Warp Connect (PowerPC Edition) environment. ø Provides virtual device support to allow sharing of devices between DOS, Windows, DPMI applications and OS/2 applications. ø Provides LIM EMS 4.0 support. ø Provides LIMA XMS 2.0 support. ø Provides DPMI 0.95 host support in the system. ø Provides support for Windows 3.1 applications by running WIN-OS/2 from OS/2 Warp (Intel) in a virtual machine. ø Provides support for network redirection of drives in a VDM. ø Provides support for user configuration of the MVM environment on a per VDM basis. ø Support Win32s applications as found in OS/2 Warp (Intel). The MVM environment provides the above listed functionalities in the OS/2 Warp Connect (PowerPC Edition) system with the help of several components from the Service Layer of the system. The service layer is a term to describe services or facilities available in the operating system, but which are not part of either the OS/2 Server or the MVM environment. The components that the MVM environment uses are: ø OS/2 Loader. The OS/2 loader is used for loading programs of attaching libraries to already running programs. ø HRM. The Hardware Resource Manager portion (HRM) is used to request and get hardware resources for a virtual machine. ø File Server. The file server provides file system services to Virtual Machines. ø Event and Session Manager. For session management and keyboard and mouse events. Subtopics: 4.2.1 OS/2 Warp (Intel) Multiple Virtual DOS Machine 4.2.2 OS/2 Warp Connect (PowerPC Edition) MVM Environment 4.2.3 Installation 4.2.4 Multiple Virtual Machine Server 4.2.5 EM86 (8086 Emulation) 4.2.6 Instruction Set Translator 4.2.7 DOS Emulation 4.2.8 Virtual Device Drivers 4.2.9 Windows Support 4.2.10 Changes to The Command Set 4.2.11 Changes to the MVM DOS Settings ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.1 OS/2 Warp (Intel) Multiple Virtual DOS Machine The Multiple Virtual DOS Machine (MVDM) architecture in OS/2 Warp (Intel) is designed to exploit the virtual 8086 (V86) mode of the 80X86 processor, which allows operating systems such as OS/2 Warp (Intel), to execute multiple DOS applications within the 80X86 protected mode environment. The MVDM Kernel controls the state and the architecture of concurrent VDMs, and is composed of the following four major components as shown in Figure 9. Figure 9. MVDM Architecture 1. The Virtual DOS Machine Manager (VDMM) This component contains the mechanism to start and interact with DOS applications. It creates, initializes, and terminates Virtual DOS Machines (VDM). 2. 8086 Emulation The 8086 emulation manages communication between 8086 instruction streams and virtual device drivers. 3. DOS Emulation This component emulates the function and operation of the DOS operating system on a per-VDM basis. DOS services are emulated with the MVDM kernel, or by invoking protected mode services provided by the OS/2 kernel. 4. The Virtual Device Driver Manager (VDDM). The VDDM loads, initializes and communicates with virtual device drivers. Virtual device drivers are required to virtualize the hardware and ROM BIOS, thereby allowing DOS applications to access hardware device and BIOS without affecting other applications in the system. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.2 OS/2 Warp Connect (PowerPC Edition) MVM Environment The MVM environment is the facility that provides DOS, Windows or DPMI support in the OS/2 Warp Connect (PowerPC Edition) operating system. Based on the OS/2 Warp (Intel) Multiple Virtual DOS Machine (MVDM) architecture, the MVM environment is built from many of the same components as the MVDM. Figure 10 shows the MVM environment architecture. Figure 10. MVM Architecture Obviously, with the change to the PowerPC platform, the MVM environment had to grow in order to support the new requirements of the PowerPC processor. For example, without the Intel 80X86 processor to cater for Intel instructions, OS/2 Warp Connect (PowerPC Edition) provides an Instruction Set Translator (IST) to do the job. The MVM environment is comprised of the following four major components: ø MVM Server A Multiple Virtual Machine server that exports a message based API to create, configure and destroy VDMs. The server maintains a database of global and per virtual machine configuration and tuning properties. ø 8086 Emulation or EM86 The EM86 component services all exceptions in a VDM, decodes the instruction that caused the exception and dispatches an appropriate Virtual Device Driver to emulate or virtualize it. ø DOS Emulation This component emulates the function and operation of the DOS operating system on a per-VDM basis. This component utilizes a DOS Emulation Service Interface (DEM) in order to access microkernel resources. ø Virtual Device Drivers A collection of Virtual Device Drivers (VDDs) that virtualize or emulate different aspects of the PC and X86 environment for the VDM. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.3 Installation The MVM Environment can be installed during the Personality Feature Installation Phase of the OS/2 Warp Connect (PowerPC Edition) install process. This means that the MVM can be installed during the OS/2 Warp Connect (PowerPC Edition) installation, or later as part of an additional installation of features. More details about the OS/2 Warp Connect (PowerPC Edition) installation is available in section "Feature Install" in topic 5.2. For the purpose of installation, the MVM environment is composed of three main components. They are: ø Multiple Virtual DOS Machine (MVM) server, which supports the Virtual DOS Machines (VDM) ø WIN-OS/2 ø Win32s Although you can install the MVM environment using the defaults, you can customize which of the sub-features of the environment that you install. Optional sub-features of the MVM Environment available are: ø DOC - Documentation Install Object includes child install objects if there are many kinds of documentation. ø DPMI - DOS Protected Memory Interface support. ø EMS - Expanded Memory Specification support. ø XMS - Extended Memory Specification support. ø Sys Util - System Utilities support includes, backup hard disk, change file attributes, display directory tree, manage partitions, label diskettes, link object modules, recover files, restore backed-up files, and sort filters. WIN-OS/2 and Win32s installation is optional, and is dependent in the MVM server (with DPMI support) also being installed. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.4 Multiple Virtual Machine Server The MVM server in OS/2 Warp Connect (PowerPC Edition) provides the mechanism for the creation, initialization and destruction of Virtual Machines. A Virtual Machine is an environment in which a DOS, Windows or DPMI application can execute. Although providing somewhat behind the scenes support, the MVM server is integral to the MVM environment. The server provides functionality that is similar to that of both the Virtual DOS Machine Manager (VDMM) and the MVDM Kernel found in OS/2 Warp (Intel). The MVM server is closely integrated into the OS/2 Warp Connect (PowerPC Edition) environment. The MVM server starts via a RUNSERVER= entry in the CONFIG.SYS when OS/2 Warp Connect (PowerPC Edition) boots. Additional information on the OS/2 Warp Connect (PowerPC Edition) boot process is found in section "Startup" in topic 4.1.5. The MVM server provides the following services to the MVM environment: ø Identifies the hardware environment that it is running in (for example, the PowerPC) and loads the appropriate module binaries into the MVM environment. ø Loads and initializes the other components in the MVM environment by using the system loader in the task manager. ø Provides services to create, manage and destroy X86 VDMs in which DOS, Windows or DPMI applications can be executed. These services are exported to other servers in the OS/2 Warp Connect (PowerPC Edition) service/personality layer in the form of a message based API. ø Exports a set of services to other components in the MVM environment as well as other components in the OS/2 Warp Connect (PowerPC Edition) service/personality layer to control the execution state of the Virtual DOS Machines. ø Provides a set of services to allow per VDM configuration to be done. This allows users to configure and control the resources associated or needed by the application that they need to execute in a particular VDM. Although the MVM environment is structured as an OS/2 task it still utilizes the resources provided by the microkernel. It does this through the use of ports. A port is a unidirectional communication channel between a client that requests a service and a server that provides the service. Ports are discussed in more detail in section "Inter Process Communication (IPC)" in topic 2.1.3. In future releases of OS/2 Warp Connect (PowerPC Edition), the MVM environment will move away from the port communication structure and communicate directly to the OS/2 server. The MVM server itself is comprised of a number of components. Many of these components provide similar services to those already found in the OS/2 Warp (Intel) environment. The MVM server components are: ø Boot/Initialization This component of the MVM server is the one that performs boot time initialization of the MVM environment. ø Event List Management The Event List Management component of the MVM server exports a set of services that are used by the emulation code (EM86 + VDDs) components in the MVM environment to register event handlers for various events. ø Virtual Machine Manager The virtual machine manager (VMM) supports services that control the operation of virtual machines though creation to termination. Access to the services are through the SERVICE_PORT. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.5 EM86 (8086 Emulation) The 80X86 emulation component (EM86) emulates 80X86 instructions and provides the functions required to support emulation to the other components of the MVM server. On an Intel based machine, EM86 would use the virtual 8086 mode of the Intel processors to provide low-level emulation functions. On the PowerPC, EM86 uses the services provided by the Instruction Set Translator (IST) to support the functions that it provides. The EM86 components emulate some INT instructions, all IOPL-sensitive instructions, and some I/O instructions for 80X86 processors. These components also helps virtual device drivers emulate INT and I/O instructions. EM86 consists of the following major components: ø Boot-time initialization ø Client creation-time initialization ø Instruction emulation ø Virtual Device Helper (VDH) functions ø Hardware interrupt dispatcher. EM86 uses the Instruction Set Translator (IST) to support the emulation of Intel instructions on the PowerPC. Low level instruction is performed by the IST. EM86 decodes instructions using the IST and passes control to the appropriate handler. If the instruction is unsupported or cannot be decoded, an invalid opcode (INT 6) is reflected to the VDM. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.6 Instruction Set Translator The Instruction Set Translator (IST) is a mapping layer to allow Virtual Device Drivers to use the current Virtual Device Helper (VDH) services with the IST. The IST also provides a black box emulator that emulates the Intel instruction set on non-Intel (PowerPC) hardware. This means that the Instruction Set Translator is the only area that understands Intel instructions on the non-Intel (PowerPC) machines. The use and functionality of the IST is not restricted to the MVM environment. When the Intel Binary Support for OS/2 applications is added to OS/2 Warp Connect (PowerPC Edition) in a future release, the IST will be used to provide the required emulation support. The architecture of the DOS emulation is such that the IST is perceived as a replaceable module. That is, if the MVM environment was moved to an Intel based platform, then the function of the IST could quickly and easily be replaced by the actual Intel 80X86 processor. The performance of the IST exceeds that of most of the other DOS/Windows software emulators that are available in the market today. In order to achieve this result it was necessary to limit the function supported by the IST. A brief summary of the limitations of the IST are listed below: ø Numeric coprocessor support is limited to 64 bits, instead of the 80 bits supported in the Intel Architecture. ø No limit checking for selectors. ø No checking of selector attribute bytes. ø No page table emulation (no page level memory protection or per-page memory management for protected mode applications). The means that it will not be possible to support the DPMI 0.95 demand-page memory functions. ø The IST is 386 only. Instructions specific for 486 (and above) are not supported. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.7 DOS Emulation The DOS Emulation Kernel emulates the DOS environment (such as DOS data structures and interrupt 21s) for each DOS session. DOS emulation is broken into two major pieces, one half that runs in the Intel address space (V86 mode on Intel or real mode in the IST) and the other half runs natively. Figure 11 shows the two parts of the DOS emulation servicing an interrupt in the MVM environment. Figure 11. MVM Interrupt Processing The piece of the DOS emulation running in the Intel space receives application requests in the Intel address space, updates the appropriate data structures, and then passes the request to the native piece of DOS emulation. The native piece of code acts of a router and routes the request to the appropriate worker routine, such as a file serve routine. The return code from the worker routine is then passed back to the Intel piece of code, so that it can return the proper result to the application. The two components of the DOS emulation are: ø DOS Kernel. The DOS Kernel services the requirements of the DOS function calls that do not require services from outside the Intel space. An example of this would be the alloc_mem function call. ø DOS Emulation Service Interface. The DOS Emulation (DEM) Service Interface acts as a router of information requests for the DOS Kernel. The DEM interface is a PowerPC specific and is not present in the OS/2 Warp (Intel) version of the emulator. The DEM requests are routed to either a Personality Neutral Service, a Cross Personality Service, the IBM Microkernel, a Virtual Device Driver, or a Physical Device Driver. The services that the DEM layer provides include: - File I/O - File, directory, and disk I/O to include Universal Naming Convention (UNC) names. - Device I/O - I/O to devices to include IOCtl support. - Named Pipe I/O - Support for the client end of named pipes. - Semaphores - All semaphore support. - Internationalization - Internationalization to support both DBCS and Unicode. - Other - Other services such as initialization and termination support. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.8 Virtual Device Drivers DOS applications tend to access the hardware resources like devices directly. In order for multiple DOS applications, each running in a Virtual Machine, to access physical hardware devices, each virtual machine must be provided with a set of virtual interfaces to these devices. This is so the actions of one application running in a virtual machine does not affect the state of the device as perceived by other entities in the system. The Virtual Device Drivers (VDD) provide these virtual interfaces. The VDD model used for the drivers is mostly unchanged since OS/2 Warp (Intel). The virtual device drivers that are supplied with OS/2 Warp Connect (PowerPC Edition) provide the same level of support that is available in OS/2 Warp (Intel). Although the VDD model is mostly unchanged, there has been some changes to the implementation of the virtual device drivers in the OS/2 Warp Connect (PowerPC Edition) environment. One of the most obvious changes is that the virtual device drivers are no longer loaded at ring 0. Along with some of the physical device drivers, they are now at the user (ring 3) level of the operating system. In OS/2 Warp (Intel), all of the virtual device drivers stored in the system as individual .SYS files and are loaded from the CONFIG.SYS file. In the first release of OS/2 Warp Connect (PowerPC Edition), that has changed. The base VDDs are found in the system dynamic link librariy MVDM.DLL, while the installable VDDs are still listed in the CONFIG.SYS file. Subtopics: 4.2.8.1 Available VDDs in OS/2 Warp Connect (PowerPC Edition) ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.9 Windows Support The Windows support for the MVM environment is provided by WIN-OS/2. This is the same support that is currently provided in OS/2 Warp (Intel) The windows support provides Windows 3.1 application compatibility as well as support for Win32s version 1.15 and below applications . The performance of the WIN-OS/2 subsystem is heavily dependent on the Instruction Set Translator (IST). On the PowerPC, all of the WIN-OS/2 code runs in the emulated Intel space, so the performance of the IST and the MVM server are pivotal to the performance that the Windows system will display. By providing the same support for DOS and DPMI applications as OS/2 Warp (Intel), WIN-OS/2 is able to run unmodified for MVM. The OS/2 Warp Connect (PowerPC Edition) WIN-OS/2 implementation provides support for the Windows 3.1 API set (with the exception of VxD support). ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.10 Changes to The Command Set OS/2 Warp Connect (PowerPC Edition) and the MVM environment, continue to offer the user a command line interface to the system. In OS/2 Warp (Intel), due to the similarity of the OS/2 and DOS versions of these utilities, many of the utilities were coded using the Family API (FAPI) so that a single binary executable resided on the system. With the lack of 16 bit OS/2 support in the current release, FAPI is no longer an option. However, by splitting the utilities into separate executables, the DOS versions can offer a flexibility that was unavailable in the previous OS/2 releases. Future releases of OS/2 Warp Connect (PowerPC Edition) will allow DOS only devices such as network redirectors and other block device drivers. In addition, the operational level of the DOS compatible function can be improved beyond what real DOS is capable of. The START command, or the seamless integration with OS/2 and Windows programs can be done in a superior fashion as compared with similar offerings in the marketplace. The DOS functionality for the utilities has been taken from PCDOS 6.3. For this reason, and other architecture considerations, several OS/2 and DOS commands and utilities are no longer available in OS/2 Warp Connect (PowerPC Edition). The changes to the available utilities are shown in Table 2. ______________________________________________________________________________________________________________________ | Table 2. Changes to DOS Utilities | |__________________________ _________________________________________________________________________ ________ ________| | | | | | | | | | | | | | Added | Deleted| | | | | | | Utility Name | Comments | | | |__________________________|_________________________________________________________________________|________|________| | ARABIC | A new command to OS/2 Warp Connect (PowerPC Edition), it provides for | &check.| | | | ARABIC character support in VDM sessions. | | | |__________________________|_________________________________________________________________________|________|________| | BOOT | Since OS/2 and DOS are not available on the PowerPC platform as native | | &check.| | | systems there is nothing to dual-boot to. | | | |__________________________|_________________________________________________________________________|________|________| | CACHE | Caching has been reimplemented in OS/2 Warp Connect (PowerPC Edition), | | &check.| | | making this command no longer required. | | | |__________________________|_________________________________________________________________________|________|________| | CHOICE | This command is used in batch files to display a specified prompt. The | | | | | prompt provides the opportunity to choose whether or not the batch | &check.| | | | program is to be processed. | | | |__________________________|_________________________________________________________________________|________|________| | CRC | Gives a Cyclic Redundancy Check (CRC) number for a filename. The | | | | | number can be used to uniquely identify a file. An OS/2 equivalent | &check.| | | | function also exists in OS/2 Warp Connect (PowerPC Edition). | | | |__________________________|_________________________________________________________________________|________|________| | CREATEDD | New System Management routines with regard to dumps and dump taking, | | &check.| | | has removed the need for this command. | | | |__________________________|_________________________________________________________________________|________|________| | DELTREE | Allows users to delete whole directory trees from a DOS command line. | &check.| | | | There is no equivalent OS/2 command line function. | | | |__________________________|_________________________________________________________________________|________|________| | DRVLOCK | Locks or unlocks the specified drive or socket. | &check.| | |__________________________|_________________________________________________________________________|________|________| | E | A full screen text editor for DOS. | &check.| | |__________________________|_________________________________________________________________________|________|________| | EDLIN | This editor was replaced with the DOS E editor. | | &check.| |__________________________|_________________________________________________________________________|________|________| | HELPMSG2 | The help system has been re-worked make this file redundant. | | &check.| |__________________________|_________________________________________________________________________|________|________| | NLSFUNC | The internationalization in OS/2 Warp Connect (PowerPC Edition) has | | &check.| | | replaced this function. | | | |__________________________|_________________________________________________________________________|________|________| | REXX | Added REXX support for DOS sessions, similar to that found in PC DOS | | | | | 7.0. This change allows REXX program execution in both DOS and OS/2 | &check.| | | | sessions in OS/2 Warp Connect (PowerPC Edition). | | | |__________________________|_________________________________________________________________________|________|________| | RC | Not supported due to architecture change. | | &check.| |__________________________|_________________________________________________________________________|________|________| | SETBOOT | This utility is part of a multiboot system, which is not an OS/2 Warp | | &check.| | | Connect (PowerPC Edition) Release 1 function. | | | |__________________________|_________________________________________________________________________|________|________| | SETVGA | Not supported in this release. | | &check.| |__________________________|_________________________________________________________________________|________|________| | SHARE | Added DOS share.exe support to VDM sessions in addition to support | &check.| | | | already provided by OS/2. | | | |__________________________|_________________________________________________________________________|________|________| | START | This utility allows users to start new sessions from the command shell. | &check.| | | | This function was restricted to OS/2 sessions in OS/2 Warp (Intel). | | | |__________________________|_________________________________________________________________________|________|________| | SVGA | Not supported in this release. | | &check.| |__________________________|_________________________________________________________________________|________|________| | SYSLEVEL | Allows the user to check the syslevel of the DOS components. | &check.| | |__________________________|_________________________________________________________________________|________|________| | VIEWDOC | Functionality has been rolled into the VIEW command. | | &check.| |__________________________|_________________________________________________________________________|________|________| In addition, due to the lack of FAPI support in OS/2 Warp Connect (PowerPC Edition), several more utilities are now found in the MDOS directory. These commands perform the same function as they did previously in OS/2 Warp (Intel), and have native OS/2 equivalents. They are: ø CHKDSK ø EAUTIL ø PATCH ø UNDELETE ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.2.11 Changes to the MVM DOS Settings The DOS settings that are used to configure MVM sessions in OS/2 Warp Connect (PowerPC Edition) are very similar to those available to current users of OS/2 Warp (Intel). However, several changes have been made, with new DOS settings appearing in OS/2 Warp Connect (PowerPC Edition), and others being no longer supported. A summary of these changes are shown in Appendix A, "Changes to MVM DOS Settings" in topic A.0. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.3 Graphics Subsystem Graphics Subsystem is a part of OS/2 Warp Connect (PowerPC Edition) that is responsible for drawing all graphic requests from applications to the specific hardware output. The Graphics Subsystem exists in two components of OS/2 Warp Connect (PowerPC Edition) as shown in Figure 1 in topic 1.0: ø Presentation Services ø System Services For detail information about Graphical Subsystem in OS/2 Warp Connect (PowerPC Edition), please refer to document, OS/2 Warp Connect (PowerPC Edition), Graphical Subsystem, SG24-4639. A Part of graphics subsystem that resides in Presentation Services are: ø Graphics Engine ø Translation Layer (GRE2VMAN, GDI2VMAN) Graphics Engine will be discussed in "Graphics Engine" in topic 4.3.2. Translation Layer is a part of GRADD Model that will be described in "PM Video Device Driver" in topic 4.3.3. The rest of the graphics subsystem that resides in System Services are: ø VMAN ø GRADD ø Softdraw ø Base Video Services VMAN, GRADD and Softdraw are part of Graphics Subsystem which will be discussed in "PM Video Device Driver" in topic 4.3.3. Base Video Services will be discussed in "Base Video Services" in topic 4.3.4. Subtopics: 4.3.1 Graphics Subsystem Overview 4.3.2 Graphics Engine 4.3.3 PM Video Device Driver 4.3.4 Base Video Services 4.3.5 Fonts ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.3.1 Graphics Subsystem Overview This section will describe the overview of the new model that is specifically designed for OS/2 Warp Connect (PowerPC Edition). The Graphics Subsystem of OS/2 Warp Connect (PowerPC Edition) provides the same functions as OS/2 Warp. There are changes and enhancements due to Microkernel architecture. The new video device driver can be written by the developer using Graphics Adapter Device Driver (GRADD) APIs. GRADD will simplify the device driver by providing a smaller number of mandatory functions to be implemented. The structure of OS/2 Warp Connect (PowerPC Edition) Graphics Subsystem is shown in Figure 12. Figure 12. OS/2 Warp Connect (PowerPC Edition) Graphics Subsystem PMGPI The Graphics Programming Interface provides the means used by applications to do graphic requests. For example, to draw an arc and/or to write a text at a certain position on the screen, an API call is made to PMGPI. PMWIN The Window Manager is responsible for creating, maintaining and destroying windows on the PM desktop. For example, if we want to open the pop-up dialog, the mechanism will be provided by PMWIN. PMGRE The PM Graphics Engine is the core of PM System. It will be called by PMWIN and PMGPI on behalf of the applications. It works very closely with the device driver. PDs Presentation Drivers are the device-dependent tools used by Graphics Engine to map its graphics layout. Presentation Drivers will be different for every hardware supported. Softdraw Softdraw stands for Software Drawing for Non-Accelerated Graphic Operation. Softdraw will be used by Graphics Engine when it needs to do some raster graphics. Softdraw is needed to perform raster operations to a linear address space. GRE2VMAN The GRE2VMAN is also called a translation layer. It is responsible for reporting current GRADD modes and capabilities to the Graphics Engine. GRE2VMAN is the first translation layer that will be loaded if the system uses PM as the dominant personality. VMAN Video Manager is the main component of GRADD model that will be responsible for serializing the communication between access to the GRADDs and the translation layer. Video Manager can also call Softdraw for simulation. GRADD Graphics Adapter Device Drivers provides video support to all the graphics subsystems which can run on the OS/2 Warp Connect (PowerPC Edition). A GRADD contains only the hardware dependent code that is needed to graphic functions that are common among the different graphics subsystems. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.3.2 Graphics Engine This section will discuss GRADD model as a new graphics subsystem model in OS/2 Warp Connect (PowerPC Edition). Figure 13 shows the detail structure of OS/2 Warp Connect (PowerPC Edition) Graphics Engine. Figure 13. OS/2 Warp Connect (PowerPC Edition) Graphics Engine Graphics Engine (PMGRE) will receive and forward requests for graphic operations. The capability of Graphics Engine in OS/2 Warp Connect (PowerPC Edition) is enhanced and some mandatory functions are added. These enhancements will be described later in this section. The Device Driver Interface function of OS/2 Warp Presentation Driver has been changed by GRE2VMAN. The GRE2VMAN is also called a translation layer in GRADD model. It is responsible as a callpath between Video Manager (VMAN) and Graphics Engine. It is also responsible for handling the OS2_PM_ENABLE and DevEscape functions. GRE2VMAN will then forward the requests to Video Manager (VMAN) module which will handle serialization and dispatching to the correct device driver. VMAN is part of Shared Services. The display device driver for OS/2 Warp Connect (PowerPC Edition) is now called Graphics Adapter Device Driver (GRADD). GRADD can now perform the function to the specific hardware via Microkernel but it can also return RC_SIMULATE which will allow VMAN to call SOFTDRAW for simulation. Softdraw fully performs rasterization functions. In the previous version of OS/2 it can be performed also by Presentation Driver. Table 3 is the summary of OS/2 Warp Connect (PowerPC Edition) Graphics Engine Structure. ______________________________________________________________________________________________________________________ | Table 3. A Summary of OS/2 Warp Connect (PowerPC Edition) Graphics Engine | |_________ ________________________________ ___________________________________________________________________________| | No. | Module | Task | |_________|________________________________|___________________________________________________________________________| | 1. | PMGRE | Translates PM graphic primitives into PMGRE independent GRADD primitives. | |_________|________________________________|___________________________________________________________________________| | 2. | GRE2VMAN | Converts the commands and send them to VMAN using Video Manager Interface | | | | (VMI) as a protocol. | |_________|________________________________|___________________________________________________________________________| | 3. | VMAN | Responsible for serialization of GRADD updates. commands to GRADD using | | | | Graphics Hardware Interface (GHI) as a protocol. | |_________|________________________________|___________________________________________________________________________| | 4. | GRADD | Performs the operation or returning RC_SIMULATE to inform that the | | | | commands need to be simulated. VMAN then calls SOFTDRAW. | |_________|________________________________|___________________________________________________________________________| | 5. | SOFTDRAW | Simulates the commands as requested by VMAN and also fully performs | | | | rasterization functions. | |_________|________________________________|___________________________________________________________________________| The GRADD model will benefit the device driver developer since it needs a small number of functions that need to be implemented before a system can be fully functional. The structure of OS/2 Warp Connect (PowerPC Edition) Graphics Engine not only gives the easier way to enhancing the device driver but it also reduces the time for maintenance of the Presentation Driver (PD), as shown in Figure 14. Figure 14. GRE/Presentation Driver Design The Graphics engine is being designed so that a developer can create PD with minimal effort, and then incrementally add functions that support specific hardware. In order to achieve this, the new design will: ø Have the GRE manage contextual/state information ø Provide a copy of contextual/state information when the PD hooks functionality ø Provide a device contextual serialization routine ø Perform rasterization into a linear address specified by the PD ø Provide a set of device support routines ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.3.3 PM Video Device Driver This section will describe the PM Video device driver model for OS/2 Warp Connect (PowerPC Edition). The PM Video device driver model for OS/2 Warp Connect (PowerPC Edition) incorporates two models: ø Existing PM Video device driver model for OS/2 Warp ø New model called the Graphics Adapter Device Driver (GRADD) model OS/2 Warp Connect (PowerPC Edition) will continue to support the existing full Device Driver Interface, as described in the OS/2 2.1 Presentation Driver Reference. Existing OS/2 2.X drivers that are being ported to OS/2 Connect (PowerPC Edition) will not be forced into using the GRADD model, although it will be the recommended approach for driver developers from now on. The GRADD model design is a clean and simple architecture, giving developers the opportunity to write display device drivers very easily and quickly. The GRADD model is devided into several components that coordinate the communication between OS/2 and the available hardware. These components are: ø Translation layers (GRE2VMAN, GDI2VMAN, TAL2VAM, etc.) ø Virtual VMI VDD (VVMI) ø Video Manager (VMAN) ø Graphics Adapter Device Drivers (GRADDs) ø Softdraw The GRADD model with all its components is shown in Figure 15. Figure 15. GRADD Model The following lines explain how these components handle a basic operation: ø The translation layer sends VMAN one of the defined Video Manager Interface (VMI) commands. ø Upon receiving a VMI command, VMAN waits for a semaphore, if required. This semaphore is used to protect the hardware from more than one thread accessing a GRADD, and therefore protecting the hardware at the same time. ø VMAN then sends the hardware command to the appropriate GRADD. ø After the GRADD has received the Graphics Hardware Interface (GHI) command which is not mandatory, it has the option of performing the request operation or returning the request back to VMAN with a return code of RC_SIMULATE. The RC_SIMULATE informs VMAN that the command needs to be simulated in software. ø VMAN then calls a component Softdraw to simulate the operation. The following pages will discuss each component in the GRADD model. 1 GRE2VMAN is the first translation layer and the first component of the GRADD model to be loaded and called by the GRE. When GRE2VMAN is loaded, it calls VMAN's VMIEntry function with a VMI_CMD_INIT command. When VMAN receives a command VMI_CMD_INIT for the first time, it loads the other GRADD model components. GRE2VMAN.DLL translates the PM graphics' engine commands into VMI commands. GRE2VMAN is a passthrough from PMGRE to VMAN. PMGRE has also been optimized to package the drawing command before calling GRE2VMAN. This technique reduces the number of calls down to the video subsystem and helps overall performance. The GRE2VMAN component will also be responsible for handling the OS2_PM_ ENABLE and the DevEscape functions. 2 GDI2VMAN is a Windows translation layer. It translates the Windows graphics engine (GDI) commands into VMI commands. GDI2VMAN calls VMAN directly via a virtual device driver called VVMI (Virtual Manager Interface). Windows support is accomplished this way. 3 The Virtual VMI VDD (VVMI) component provides only a callpath from GDI2VMAN to VMAN. 4 Video Manager (VMAN) is the primary component in the GRADD model, as shown in Figure 15. VMAN is responsible for the following: ø Communication ø Input Management VMAN is a link between the translation layers and the GRADDs and is used to serialize the communication between these components. VMAN relies on a special protocol to receive requests from the translation layers. The VMAN protocol is called the Video Manager Interface (VMI). This protocol consists of small set of operations which are individually identified by a function number. The translation layers communicate to VMAN via one entry point using export functions. For input management, mouse movement is sent from the Event Window Server (EWS) to the Video Manager (VMAN). The mouse event thread calls VMAN which calls the GRADD to perform a mouse pointer update. The GRADD has the options to update the pointer or return to VMAN for simulation. When RC_SIMULATE is returned, then VMAN will simulate the pointer movement using the regular BitBlt commands. 5 The Filter GRADD component is shown in Figure 15. This component is optional in the GRADD model. There is no way anyone can anticipate the changes in the graphics' hardwares. We must allow a mechanism to extend the architecture in a manner which takes fullest advantage of the new hardware. The Filter GRADD provides a way of modifying the GRADD's behavior without rewriting and compiling the GRADD. A Filter GRADD is placed between VMAN and the GRADD. This component provides now an extra link to the GRADDs. This is called chaining. The GRADD model can be extended by using the VMI_CMD_EXTENSION command. An extension can be written to pass its own defined commands to a GRADD or a new GRADD can be written to handle the additional support for a given extension. 6 The GRADD as shown in Figure 15 is a hardware specific device driver. GRADDs contain only a small set of common functions, which are designed to act as building blocks for the larger more complex operations. These complex operations are required by the GRE. GRADDs are the only components in the model that have direct access to the hardware. A GRADD contains only the hardware specific code to exploit the accelerated features of a specific graphics adapter. For most developers, the GRADD will be the only code that needs to be written. GRADD relies on a special protocol to receive requests from VMAN. The GRADD protocol is called Graphics Hardware Interface (GHI). A GRADD receives all of the operations from VMAN via a single export function called HWEntry. HWEntry is the exact same as the VMIEntry. 7 Softdraw is the component in the GRADD model, as shown in Figure 15, that, provides the Software simulation. Softdraw consists of a generic graphics library to be used by VMAN and the system for software simulations. Softdraw exports two functions called SDBitBlt and SDLine that are used by VMAN to simulate in software bitblt and line operations, respectively. Softdraw can draw the bits directly into the bitmap, if given a pointer to a linear address, a VRAM bitmap or system bitmap. The Softdraw component will support rasterization concepts. Software simulation allows a developer to write the driver in incremental stages, rather than writing the entire driver up front. Once the mandatory functions are completed, a developer can use the software simulation to simulate the non-mandatory functions. When the non-mandatory functions are coded to exploit the capabilities of the graphics adapter, the result can be compared to the result of the software simulation. This is a way for the developers to assure that their PM drivers look consistent to drivers written for different hardware platforms. The PM Video Device Driver model for OS/2 Connect (PowerPC Edition) is shown in Figure 16. Note the Graphics Engine will either dispatch drawing requests to a driver coded to the existing DDI interface or to the new driver coded to the GRADD model via the Video Manager(VMAN) interface. Figure 16. OS/2 WARP Connect (PowerPC Edition) PM Video Device Driver Model ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.3.4 Base Video Services The Base Video Subsystem is comprised of a shared module (VIDEOPMI) which communicates to/from the protected mode video device driver (BVHSVGA - OS/2 Warp Connect (PowerPC Edition)), as well as the virtual video device driver (VSVGA - Multiple Virtual Machine). It is the part of Presentation Manager which maintains compatibility with text mode application and graphical system in protected mode. The discussion of Base Video Subsystem in OS/2 Warp Connect (PowerPC Edition) will deal with the design and function of VIDEOPMI. VIDEOPMI is a neutral subsystem which provides services to: 1. BVHSVGA for OS/2 full-screen sessions 2. BVHWNDW for OS/2 windowed session 3. VSVGA for VDMs 4. VIO API for 32-bit programming interface 5. Base Video Subsystem All these callers will be discussed separately in "Text Mode in OS/2 Warp Connect (PowerPC edition)" in topic 4.3.4.1. Virtual Video Device Driver which provides DOS Full screen and windowed support will be discussed in " Virtual Video (VVIDEO)" in topic 4.3.4.2. VIDEOPMI will be called by GRADD when an application requests for example, drawing a line in a OS/2 windowed. The structure is shown in Figure 17. Figure 17. VIDEOPMI Accessed from GRADD The design of VIDEOPMI is built around information contained in the Protect-Mode Interface (PMI) file. It is based on the SuperVGA Protect-Mode Interface (SVPMI) VESA standard. The PMI file will contain data and commands necessary to provide support for modes beyond VGA in a non-BIOS environment. Adapter manufacturer or display device driver provider is responsible for providing PMI file. The main goals of VIDEOPMI are: ø To centralize all of the setmode related services ø To provide a consistent interface which is not dependent on any BIOS services ø To facilitate multiple adapter support and dynamic video configuration In its implementation, VIDEOPMI will be called by the callers. All functions will request one entry point. All calls are then routed to the appropriate routine. VIDEOPMI will not hold any instance data, all data must be maintained by the caller. All data maintained by VIDEOPMI will be allocated dynamically as shared data during initialization. And since the data will be shared, it will need a handle which is the base address of data allocated during initialization. This handle will be notified and referenced to every caller. Initialization of VIDEOPMI takes the following four main steps: 1. Allocating and initializing internal memory management routines 2. Loading and parsing of the PMI file 3. Setting up addressability to code and data 4. Notifying the Virtual Video Driver of entry points and handle values The most important file in VIDEOPMI is Protect-Mode-Interface file. This file resides in directory \OS2. The first release of OS/2 Warp Connect (PowerPC Edition) provides 3 PMI files: WD_90C24.PMI, S3_864.PMI and S3_928.PMI. These files are readable and will be parsed by VIDEOPMI Initialization and put in shared memory as an internal linked-list. The PMI file is responsible for: ø Describing a graphics adapter to the OS/2 ø Providing means to set, save and restore video modes in Protected-Mode ø Providing parameters for the adapter virtualization in multiple DOS session. The PMI language and its interpreter can facilitate dynamic hardware configuration, which includes port remapping, adding or removing an adapter and its PMI definition, changing the attached display and multiple instances of the same video hardware. It also facilitates different refresh rate support and programming of external video-support chips, such as clock chips or smart DACs. PMI file should list default adapter port configuration and mode sections which are capable of supporting different refresh/monitor setups. Monitor configuration, port mapping, and selection of the adapter instance are performed by components other than VIDEOPMI. The PMI file can list one or more adapter description starts with its hardware section, followed by IdentifyAdapter and a number of support sections and a list of all available modes with the actual hardware sequence required for a successful mode set from any hardware state of the adapter. If multiple adapters are listed, support sections for each adapter are considered private and cannot be referenced from other adapter descriptions. PMI files are to be provided by the video chip or adapter manufacturers, or by the providers of the display drivers. The file should be part of the video adapter installation kit, either as a pre-manufactured flat file or one just created by the OEM's installation utility. OS/2 Warp Connect (PowerPC Edition) Installing utility will add the file into the OS2.INI file with its full pathname and with adapters OEMString identifier. PMI services for a recently installed adapter are available as soon as the hardware described in its PMI file is installed and available. The adapter is considered available if IdentifyAdapter section in the PMI file returns true. Subtopics: 4.3.4.1 Text Mode in OS/2 Warp Connect (PowerPC edition) 4.3.4.2 Virtual Video (VVIDEO) 4.3.4.3 Virtual Windows (VWIN) ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.3.4.1 Text Mode in OS/2 Warp Connect (PowerPC edition) The need for the VIO and Keyboard calls has not gone away, and to protect legacy applications they must continue to be supported. There also remains the needs for a simple program video and keyboard interface. While PM gives a rich graphical interface, it is difficult to write a simple PM program just for simple requirements for keyboard and screen output. OS/2 Warp Connect (PowerPC Edition) has to provide a simple text mode interaction. In OS/2 Warp Connect (PowerPC Edition) there is a legacy of VIO APIs and in DOS there is a legacy of BIOS and direct hardware I/O. OS/2 Warp Connect (PowerPC Edition) provides base video support by implementing 32-bit versions of most of the OS/2 1.x VIO calls, while for DOS applications Multiple Virtual Machine (MVM) provides textmode support using VDDs. More discussion on MVM can be read in "The MVM Environment" in topic 4.2. Since the current APIs are 16 bit only, binary compatibility with existing applications is not possible. However, in most cases it is possible to move to the 32-bit VIO APIs by doing only a recompile. The concept in OS/2 Warp Connect (PowerPC Edition) provides a simple graphic interface based on a generic monospaced rectangular text window where each character has an attribute. This can be implemented on any hardware base. OS/2 Warp Connect (PowerPC Edition) has an integrated OS/2 Base Video Handler and Presentation Manager so that all user interaction in OS/2 goes through Presentation Manager. Full screen sessions are in fact just PM Windows with no border. PM can then decide whether to use a graphical mode or hardware text mode to actually display them. Both DOS and OS/2 sessions are then movable between windowed and full screens. This requires that the font be scaled to match the size of the physical screen (unlike the normal maximize). The OS/2 text mode support (OS2CHAR) provides a common set of video code to implement both full screen and windowed VIO. OS2CHAR is a component of the OS/2 Presentation Manager which processes input for OS/2 sessions. OS2CHAR is maintained by a per session logical video buffer. The base video handlers are implemented as VIDEOPMI which is documented in "Base Video Services" in topic 4.3.4. These are called from the OS/2 and MVM to do mode set, save, and restore. The BVS (Base Video Services) and BVH (Base Video Handler) layers no longer exist. Most of the functions have been moved to VIDEOPMI, and the rest is moved directly into the OS2CHAR implementation. The consequences are that all video presentation drivers must support the small number of AVIO calls. In OS/2 Warp Connect (PowerPC Edition) implementation, these functions are implemented by the graphics engine. The structure of Text mode processing in OS/2 Warp Connect (PowerPC Edition) will be basically the same as Figure 17 in topic 4.3.4 since OS2CHAR is only the part of PM. The more detail structure including MVM (DOS) module is shown in Figure 18. Figure 18. OS/2 Warp Connect (PowerPC Edition) Text Mode Event Server is a part of Event and Window Services (EWS). It runs as a thread which is responsible for processing the event input port. Event input port is a microkernel port which receives messages from the interrupt logic for the keyboard and mouse devices. More discussion on EWS could be seen in "Event and Window Services" in topic 3.2. Return codes from the VIO calls are changed from 16-bit API (USHORT) to 32-bit API (APIRET) and most USHORTs in the parameter lists have been changed to ULONG. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.3.4.2 Virtual Video (VVIDEO) Multiple Virtual Machine (MVM) Environment is the part of the OS/2 Warp Connect (PowerPC Edition) operating system that is responsible for providing the DOS/WINDOWS/DPMI program compatibility. Virtual Video (VVIDEO) is one component of MVM that is responsible for routing all the video requests to hardware. The VVIDEO component processes INT 10h requests for video events from the v86 thread and services them. Virtual 8086 mode is historically a component of 80386 intel chip which enables system software to emulate an 8086 environment with a virtual machine. In PowerPC, it will use 8086 Emulation Component (EM86) which is part of MVM. The VVIDEO exists in three parts: ø I/O Thread ø INT 10h Emulator It hooks interrupts generated by the DOS application. It also requests query or set the video state from the v86 thread and services them. ø Port Handler Routines. It services In and Out requests for the video ports. It also hooks all relevant video ports. The VVIDEO consists of the following components: 1. Boot-time Initialization This component performs the global initialization at the MVM server boot initialization time and functions as follows: ø Initializes the global data structures ø Registers the user handler VVCreate with the MVM server and must be called every time a new VDM is created 2. Client Creation-time Initialization (VVCreate) The client creation-time initialization component is called every time a new virtual DOS machine (VDM) is created. The VVCreateVM function is called in the context of the newly created VDM and does the following: ø Installs INT 0x10 hook handler, VVINT10Hook ø Installs video port handler, VVIOHookHandler for the device dependent ports ø Communicates with the SVGAPMI PNS to gain port rights to the video hardware 3. Software Interrupt and port I/O emulation Instruction emulation is provided through the Instruction Set Translator (IST). IST is responsible for emulating Intel instructions on non-Intel machines, such as the PowerPC. It provides 386 ring 3 protected mode and real mode. IST is the only module that understands Intel instructions, and provides services that the rest of MVM depend upon to run DOS and Windows applications on a PowerPC. I/O port requests will be passed on to virtual video provided that the virtual video driver has called VDHInstallIOHook. Conversion of Intel based port I/O to the appropriate memory mapped load-and-store will accomplished in the IST. Figure 19 provides a general view of the virtual video device driver architecture. Figure 19. VVIDEO Internal Architecture For optimal performance and compatibility, the Video VDDs support full-screen operation. For convenience, an option appears on the VDM system menu to convert the VDM from Windowed mode to Full-screen mode and back. The Video VDDs support full-screen operation by doing the following operations: ø Registering foreground/background screen-switch notification hooks with the VDM Manager ø Utilizing the save/restore video buffer services which is provided in the PNS of base video ø Installing I/O hooks to shadow key video port accesses ø Mapping physical video memory into the appropriate video address space ø Coercing text mode fonts to match the currently selected codepage ø Providing pointer drawing services to the mouse VDD to define, draw and erase pointer images ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.3.4.3 Virtual Windows (VWIN) Virtual Windows (VWIN) is a virtual device drive that allows a Windows program to run on the OS/2 2.x desktop, side by side with OS/2 applications and other Windows applications. It is the link that passes messages from one GUI to another so that both environments can know about and adjust for each other. In the first release of OS/2 Warp Connect (PowerPC Edition), seamless will work the same, but the components will be implemented differently to fit the OS/2 Warp Connect (PowerPC Edition) Architecture. In OS/2 Warp Connect (PowerPC Edition), VWIN will provide a number of services to facilitate the communication between Win-OS/2 and the presentation task. Win-OS/2 will use INT 66h to access it. VWIN will exist in each VDM and do the following tasks: ø Receive all messages from presentation task ø Send all Win-OS/2 messages The presentation task will use APIs, generated with MIG (Message Interface Generator), to send and receive messages from Win-OS/2. The exchange of messages between the VDM task and the presentation task represents a peer-to-peer form of client/server communication. At one point, the VDM may be the server, handling messages sent from another VDM or the presentation task. At another point, the presentation task may become the server, handling requests from the VDMs. In OS/2 Warp Connect (PowerPC Edition), WinShield will call into VWIN as it does in OS/2 Warp by executing an INT 66h, causing the Interrupt Handler to execute the VWIN entry point function for Win-OS/2. VWIN in VDM needs send rights to the port of VWIN in presentation task in order to send messages. To receive a message, a stub routine will exist that listens at VWIN's receive port, waiting for incoming messages. Multiple threads will exist to receive the messages. They are threads to receive shield messages, error messages and clipboard/DDE messages. Once a message arrives, it will be placed on a local message linked list. WinShield can then access the list through an INT 66h call to VWIN. The VWIN Central Services Task will be started by the presentation task VWIN code. The following list are the tasks of VWIN Central Services Task: ø Handles all clipboard/DDE requests ø Holds the master clipboard ø Contains a list of all VDMs and the presentation task ø Routes the broadcast messages from the VDM or Presentation Task using a list of all VDMs and the presentation task Overall message flow of OS/2 Warp Connect (PowerPC Edition) can be seen in Figure 20. Figure 20. Overall Message Flow of OS/2 Warp Connect (PowerPC Edition) When the presentation task VWIN initializes, it creates the VWIN Central Service Task. It provides it with a send right to the presentation task VWIN port. The MVM Server creates the VDM. It passes to the new VDM a send right to VDM Central Services Task. When the VDM VWIN initializes, it will send its information, along with a send right to itself, to the VWIN Central Services Task. The VWIN Central Services Task then passes the VDM VWIN send right to the presentation task VWIN. The presentation task VWIN then passes a send right to its port to the VDM VWIN. In OS/2 Warp Connect (PowerPC Edition), the new video engine/video manager (VMAN) will provide the services found in the VWIN display driver routines. More discussion on VMAN could be seen in "PM Video Device Driver" in topic 4.3.3. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.3.5 Fonts This section will describe the font support of OS/2 Warp Connect (PowerPC Edition). OS/2 Warp Connect (PowerPC Edition) will support generic fonts and can be used by all presentation drivers. The generic font can either be an outline or image font. The outline font technology supported depends on the Intelligent Font Interface (IFI) font drivers that are installed on OS/2 Warp Connect (PowerPC Edition). The following figure shows font support for OS/2 Warp Connect (PowerPC Edition). Figure 21. OS/2 Warp Connect (PowerPC Edition) Font Support OS/2 Warp Connect (PowerPC edition) will support the following font formats as shown in Figure 21. ø IBM UNI font-file format ø IBM Combined font-file format ø OS/2 PM font-file format ø Adobe Type 1 font-file format ø Adobe Composite font-file format called NCF format ø Truetype Glyph Fonts are applied to a table called a code page. A code page has several entries which contain different symbols. These symbols usually include letters, numbers, and special characters. Each of these symbols or images in a code page is called a glyph. Each entry in the code page is called a code point. A code point is an index into a code page to identify a glyph. For example if you take an ASCII code page, you would notice code point X'31' would have a glyph for the character "1" defined in it. Glyphlist The glyphlist name is the name that identifies a set of character glyph names and font index sequence of the character glyph set. All physical fonts are associated with a glyphlist name. Glyph Index Translation When an application draws a text string, the graphics engine parses the text string using a code page associated with the device context of the target device and translate it into font indices or indexes for the physical font. This is called Glyph Index Translation. OS/2 Warp supports only the character glyphs which are defined in the PM383 glyphlist at present. Six more glyphlists have been added to OS/2 Warp Connect (PowerPC Edition). These added glyphlists enable the graphics engine to support new country and new language fonts. OS/2 Warp Connect (PowerPC Edition) supports the following glyphlists: ø PM383 383 Character glyphs are defined in this glyphs are defined in this glyphlist. ø UNICODE Consists of the UNICODE specification adopted by the International Organization for Standardization (ISO) as ISO 10646. ø SYMBOL Font specific encoding used to define a symbol character set. ø PMJPN PM383 extension for the Japanese language. ø PMCHT PM383 extension for the Traditional Chinese language. ø PMKOR PM383 extension for the Korean language. ø PMPRC PM383 extension for the Simplified Chinese language Graphics engine fonts: The graphics engine (GRE) reads and parses the following font formats directly: ø IBM Combined font-file format This a new format being supported by OS/2 Warp Connect (PowerPC Edition), which will be described later in this section. ø OS/2 PM font-file format This is the OS/2 2.1 font-file format which is designed for small character sets and will be supported. ATM IFI font driver font: The ATM IFI font driver supports the following font file formats: ø Adobe NCF font-file format This is the Adobe new composite font format designed for small and large character set fonts. ø Adobe Type 1 font-file format This is the Adobe Type 1 font file format designed for small character set fonts. The Object Font Metrics (OFM) file format was enhanced in order to support the UNICODE glyplist. Raster IFI font driver font: The following font-file format is supported by the Raster IFI font driver. ø IBM UNI font-file format The Uni font-file format is designed for image fonts which have large characters set in the font file such as the Double Byte Character Set (DBCS) and the UNICODE encoding. The Uni font-file format is a super set or extension format of the OS/2 2.1 PM font-file format. Trutype IFI Font Driver Font: The Trutype IFI driver font is a new font driver that is developed to support the widely available true type fonts in the market place. The driver font supports the following font file format: ø Truetype font-file format The following table is a summary of font format and glyplist support for OS/2 Warp Connect (PowerPC edition): ______________________________________________________________________________________________________________________ | Table 4. OS/2 Warp Connect (PowerPC Edition) Font Format Support | |______________________________________________________ _______________________________________________________________| | | Glyphlists | | |________ ________ _________ ________ ________ ________ ________| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Font-file formats | PM383 | UNICODE| SYMBOL | PMJPN | PMCHT | PMKOR | PMPRC | |______________________________________________________|________|________|_________|________|________|________|________| | IBM Uni Font-file format | X | X | X | X | X | X | X | |______________________________________________________|________|________|_________|________|________|________|________| | IBM Combined Font-file Format | | X | | | | | | |______________________________________________________|________|________|_________|________|________|________|________| | OS/2 PM Font-file format | X | | X | | | | | |______________________________________________________|________|________|_________|________|________|________|________| | Adobe Type 1 Font-file format | X | X | X | | | | | |______________________________________________________|________|________|_________|________|________|________|________| | Adobe NCF Font-file format | X | X | X | X | X | X | X | |______________________________________________________|________|________|_________|________|________|________|________| | Truetype | X | | | | | | | |______________________________________________________|________|________|_________|________|________|________|________| Font Cache: The graphics engine implements character glyph (bitmap) caching for IFI font driver fonts. The caching was designed to work for large characters set fonts with reasonable performance, hit ratio point of view. The following points were considered as the criteria for handling multiple large characters set font for the caching: ø High hit ratio for the given buffer size ø Linear search must be prohibited ø Fragmentation - glyphs have different sizes Intelligent Font Interface (IFI): OS/2 Warp Connect (PowerPC Edition) graphics engine enhances the Intelligent Font Interface (IFI) in order to support raster IFI font drivers, additional glyphlists, etc. This IFI driver version will be defined as IFI version 2.1 Device Specific Font: A presentation device driver can provide device specific fonts for the built-in fonts in the hardware such as a printer or a display adapter card. For the device specific font the responsibility of the glyph index translation resides at the device driver. Device drivers must recognize which code page is associated with the text string and to the proper conversion to the font indices of the device specific font. OS/2 Warp Connect (PowerPC Edition) Font object design: As we enter new markets with new character set requirements or attempt to support multilingual text, we are facing the problem of building new UGLs or combining and using an existing one. OS/2 Warp Connect (PowerPC Edition) uses a new model as shown in Figure 22. An alternative approach was taken, this design supports font objects which maintain the information about the character sets they support. Each font object will have an associated DLL which maps the ASCII or UNICODE character encodings to the character glyph definition supplied by the font. This means that we remove the notion of the system maintaining a single list of supported characters, the UGL. The advantage of this are: 1. The dependencies of the GRE on font encodings are isolated. 2. New character sets can easily be added through new fonts. 3. Multilingual text can now be supported through the UNICODE mapping support. (PowerPC Edition) Figure 22. New Model for Font Architecture Support Under OS2 Warp Connect The new model for OS/2 Warp Connect (PowerPC Edition) is shown in Figure 22. The glyphlist associated with the font is identified by the font header. This could be SYMBOL, UNICODE, PM383, PMJPN or some other name. Current bitmaps fonts have no header and are assumed to be PM383 bitmap fonts. The graphics engine (GRE) will use a table to associate the font with a DLL. The DLL will be associated with the glyphlist name. This DLL supports three functions: ø Install ø CodePointToGlyph ø UnicodeToGlyph The CodePointToGlyph and UnicodeToGlyph functions are used to do the mapping from either an ASCII codepoint or UNICODE to a 16 bit glyph index, which represents the appropriate character. The font glyph index is used to query the intelligent font interface (IFI) driver of the font to retrieve the rasterized character bitmap. The install function is used to set up the mapping tables needed for the conversions and also establishes some of the font characteristics. Some of the values established at this point are: ø Number of glyphs in the font ø Lowest value of the font index ø Highest font index value ø Set of index ranges which contain the entire set of glyphs in the font The Graphics Engine (GRE) deals with two kinds of fonts: ø Engine Fonts An engine font is a bitmap font with a defined structure. The engine fonts used today support only the characters in PM383. A table 383 entry is built with entry, size of the character and an 64k heap pointing to the character bitmap definition. This table is part of the interface to the Graphic Engine and is used by the graphic device drivers. ø IFI Fonts An IFI font is a font, outline or bitmap, and is accessed through a special interface called an IFI driver. The IFI driver accepts 16 bit glyph index and returns a rasterized image. The Graphics Engine creates a fake representation of an engine font for each IFI font that is loaded. As characters are rasterized, the entries in the header field are filled in. The display devices are not aware of the differences between engine fonts and IFI fonts. This mechanism is also a simple cache mechanism for small fonts. Large fonts use a secondary cache to store the rasterized bitmaps. Just before the display device is called to render the characters, the bitmaps are copied to the fake engine font format. In this way the display devices are also unaware of the difference between the small and large fonts, however this will have a impact in performance for large fonts. The engine font, Font Transfer Area (FTA) is supplied to the display drivers. This font will be used for existing support for PM display drivers. The following algorithm is used as shown in Table 5. This is an example where Unicode encoded text and ASCII encoded text are used. ______________________________________________________________________________________________________________________ | Table 5. Encoding Font Algorithm | |______________ _______________________________________________________________________________________________________| | No | Description | |______________|_______________________________________________________________________________________________________| | 1. | Unicode or ASCII text is passed to the GRE to be rendered in a Presentation Space (PS). | |______________|_______________________________________________________________________________________________________| | 2. | Identification of the current logical font for the PS will take place. | |______________|_______________________________________________________________________________________________________| | 3. | If ASCII text is passed get the current PS codepage. | |______________|_______________________________________________________________________________________________________| | 4. | Next the font's UnicodeToGlyph or CodePointToGlyph function will be called, which will return a font | | | index for each character in the string. | |______________|_______________________________________________________________________________________________________| | | Either the native glyphlist of the font object is Unicode, which will result in a no operation, or | |______________|_______________________________________________________________________________________________________| | | The font object will convert from Unicode to the native encoding, that is PM383. | |______________|_______________________________________________________________________________________________________| | 5. | Next the font cache will be searched for the bitmap. | |______________|_______________________________________________________________________________________________________| | | If it is a engine font then the bitmap will always be there, or | |______________|_______________________________________________________________________________________________________| | | If it is a IFI font, the bitmap may not be available. | |______________|_______________________________________________________________________________________________________| | 6. | If the bitmap is not available, approach the IFI driver for the glyph, and place it in the cache. | |______________|_______________________________________________________________________________________________________| | 7. | Copy the bitmaps to the Font Transfer Area (FTA), if required, this is not required if the font | | | caching mechanism uses the FTA directly. | |______________|_______________________________________________________________________________________________________| | 8. | The graphics driver is then called for the PS to render the bitmap. | |______________|_______________________________________________________________________________________________________| This algorithm, together with the font objects, will support multiple glyphlists and Unicode in an efficient manner. IBM Combined Font: Combined font originated from the limitation of OS/2 2.1 PM Universal Glyph List (UGL), which makes it difficult to support new languages and countries. OS/2 Warp Connect (PowerPC Edition) uses a Combined Font font architecture to overcome this limitation. The following sections will show the design and concept and also the implementation of the combined font in the graphics engine. IBM Combined Font A Graphics engine font that is dynamically created by combining several physical fonts. A application can select and use the font in the same way as a physical font. A IBM Combined font consists of the following font entries: ø Physical Font Entry: A physical font entry is a Graphics Engine heap representing a Graphics Engine generic font. This contains information such as font metrics, glyphlist name. It uses count and pointers to retrieve character glyph data and character attributes. Physical font entries are created when a new font is installed through the GreLoadFont function, and will be destroyed when it is unloaded through the GreUnloadFont function. Physical font entries are stored in two different places in the Graphics Engine heap, which are in a global shared heap to be accessed by all processes, or in an instance heap to be accessed by only one process. The physical font entries for private fonts are placed in the instance heap, and the ones for public fonts are placed in a global shared heap. ø Combined Font Entry: Combined font entry is a binary representation of IBM Combined font-file format and is located in the Graphics Engine heap. The combined font entry includes font metrics for the combined font, an array of component font entries, use count and a priority list of component fonts. The component font must be a public font. The priority list of component fonts will be used to choose a component font from the UNICODE glyph index that is translated from the text string. ___ Note ___________________________________________________________ | | | The only supported glyphlist for combined font is UNICODE. | | | |____________________________________________________________________| Component fonts may have different glyphlist. In this case, the graphics engine will do the necessary conversion from UNICODE indices to indices of the appropriate glyphlist, in order to retrieve a character glyph from the component font. There are two passes in the process of the glyph index translation of a combined font. The first pass is to translate from code points to indices of the UNICODE glyphlist. The second pass is to translate the indices of the UNICODE glyphlist to the indices of the component font glyplist. The indices returned from the second pass will be used to extract font images and attributes from the component font file. The combined font points to physical font entries in the graphics engine heap, the graphics engine must assure that all component fonts are useable for the combined font. Therefore, all physical fonts installed as public fonts must be loaded prior to loading the combined font. A combined font entry will be created when an IBM combined font is installed through the GreLoadFont function, and will be destroyed when it is unloaded through the GreUnloadFont function. Combined Font-File Creation Tool. IBM provides a font creation tool for users and national language developers for creating a IBM combined font easily. New Graphics Engine APIs The following new APIs are implemented by the graphics engine. ø GreRealizeString ø GreQueryCharOutline ø GreQueryCharMetricsTable ø GreQueryCodePageObject ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.4 Graphics Subsystem Summary From the user point of view, there are no major changes in Graphical User Interface. Users will see the same desktop and will use the same Workplace Shell as they did in OS/2 Warp. The OS/2 Warp Connect (PowerPC Edition) Graphical Subsystem has been designed as a modular system to accommodate the fast growing hardware changes. This modular design enhances the ability for the developers to maintain and develop new code for future releases of OS/2 Warp Connect (PowerPC Edition). The summary of Graphics Subsystem will be shown in Table 6. ______________________________________________________________________________________________________________________ | Table 6. A Summary of Graphics Subsystem | |_____________________________ ________________________________________________________________________________________| | Item | Description | |_____________________________|________________________________________________________________________________________| | GRE | Some functions have been moved from Presentation Driver to Graphics Engine. It will | | | be easy to maintain the Presentation Drivers. | | |________________________________________________________________________________________| | | Graphics Engine will only map the device-independent output into specific device | | | output and GRE2VMAN will act as a Device Driver Interface. | |_____________________________|________________________________________________________________________________________| | PMVDD | Uses a GRADD model that is modular in design to accommodate and assist driver | | | developers to write drivers in stages. | |_____________________________|________________________________________________________________________________________| | Base Video Services | OS/2 Full-Screen is only a part of the PM windowed application without the border. | | | OS/2 sessions are swapable between windowed and full screen. | | |________________________________________________________________________________________| | | OS/2 Warp Connect (PowerPC Edition) will not use Base Video Handler. All the | | | functionality has been moved to OS2CHAR and VIDEOPMI. | |_____________________________|________________________________________________________________________________________| | Fonts | New font-file formats have been added with more character glyphs support for these new | | | formats. | | |________________________________________________________________________________________| | | Uses a combined font architecture whereby new languages and countries can be added | | | easily. | |_____________________________|________________________________________________________________________________________| ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.5 Printing Services Printing Services in the OS/2 Warp Connect (PowerPC Edition) operating system provide functions equivalent to those that are currently available in OS/2 Warp (Intel). The requirements that the printer server (spooler) had to meet to provide this support include: ø Allow printing from both OS/2 and MVM (DOS). ø Print using the same interfaces as those used for display. ø Print data which is already in the print stream. ø Allow for serialization and prioritization of print jobs. ø Provide an application interface to allow attributes to be specified for print jobs. ø Allow printing from current OS/2 and Windows applications. The most obvious change in the printing system when comparing it to OS/2 Warp (Intel) is that, as with the other components of the architecture, the IBM microkernel is used when accessing hardware devices. Figure 23, shows the utilization of the IBM microkernel when an application is printing. Figure 23. Printing in OS/2 Warp Connect (PowerPC Edition) The components of the printer server are discussed is the following sections. Subtopics: 4.5.1 Spooler Objects 4.5.2 Printing from DOS and Windows 4.5.3 Printer Driver Support ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.5.1.1 Logical Printer (Queue) The logical printer matches the current OS/2 print queue. The user may have as many of these as they desire. There may be multiple Print Drivers and Port Drivers associated with a Logical Printer. However, at the time a spool job is opened, one of them must be selected. Normally, the default Print Driver and Port Driver are used. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.5.1.2 Print Driver The print driver matches the current OS/2 print driver object. The print driver determines the Printer Description Language used (for example, Postscript, PCL5, Dot Matrix). The print driver has a set of attributes. These are specified on a per printer, or per job basis (print properties or job properties). Many attributes can be specified in either place. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.5.1.3 Port Driver The port driver is a high level controller for data going across a port. It provides a high level interface to the physical device. The port driver handles bi-directional interface with the printer and maintains the current state of the printer. In OS/2 Warp (Intel), the port drivers were significantly enhanced to support the needs of bi-directional communications. The function of the port driver has been implemented in OS/2 Warp Connect (PowerPC Edition). However, bi-directional printer communications will not work since the required device driver support is not yet available. The persistent state of the port is kept as a set of attributes to the port driver in the registry. Normally, this data is only accessed by the spooler. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.5.1.4 Spool Job The spool job is created when an open is done of the logical printer. The spool job inherits the attributes from the logical printer, print driver and port driver. Many of these attributes may be specified on an individual job basis. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.5.2 Printing from DOS and Windows There are several methods of printing from DOS and Windows: ø Use the Windows Print interfaces which print using the GDI APIs using the same method as is used for display. ø From DOS, copy a file to a port using the copy of print command, or an application which opens the port as a file. DOS selects the logical printer associated with that port. DOS printing is done by have the OS/2 spooler perform a DosFSAttach in place of the parallel port for logical devices supported by the spooler (LPTx). The MVM Server provides a virtual device driver (VLPT) which handles the DOS side of this communication. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.5.3 Printer Driver Support OS/2 Warp Connect (PowerPC Edition) provides support for the following printers. All of the drivers are 32 bit C presentation drivers which are source compatible between OS/2 Warp (Intel) and OS/2 Warp Connect (PowerPC Edition). Unlike the current IBM printer drivers which are already 32 bit C drivers, most non-IBM print drivers will not be easily recompiled because they are written in 16 bit assembler. However, this list includes almost all of the following PC attached printers: ø IBMNULL (passthru) ø PostScript (level 1, level 2) ø HP LaserJet (III, 4) ø PPDS (4019, 4029) ø Omni driver (HP DeskJet, HP PaintJet, Epson) ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.6 System Management. One of the goals for OS/2 Warp Connect (PowerPC Edition) is to learn from past experiences and create a product that can be supported in the field in a timely and cost effective manner. In OS/2 Warp (Intel) kernel level debugging was used to isolate the failures that were encountered in the system. The OS/2 Warp Connect (PowerPC Edition) design depends instead on the serviceability-oriented instrumentation as the primary means of debugging problems. This is a radical departure from the traditional debug techniques, and has resulted in a system that can be managed in a more intelligent fashion. Additionally, since much of the systems management architecture is intended to be shared with OS/2 Warp (Intel), the serviceability of the OS/2 Warp Connect (PowerPC Edition) enhancements will eventually be incorporated within the OS/2 Warp (Intel) platform. Subtopics: 4.6.1 Installation 4.6.2 System Management Initialization Process 4.6.3 Serviceability Tools 4.6.4 Vital Product Data ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.6.1 Installation As mentioned in section "Feature Install" in topic 5.2, the OS/2 Warp Connect (PowerPC Edition) install process treats all system components as features. Based on this philosophy, the system management component is installed as a base feature. The system management install process installs all of the system management components and consists of 3 parts: ø Module Install ø Configuration Information ø Workstation identification information The installation, by default, places the systems management components into the OS2\SYSTEM\RAS directory of the boot drive. Once completed, the following ICONS will be available to the end user from the Systems Management folder: ø Syslog Display - Utility to display error log details. ø FFST Configurator - First Failure Support Technology (FFST) configuration utility. ø Dump Formatter - PMDF Dump formatter. ø Trace Formatter - Utility to display trace entries. ø SYSLEVEL - Utility to query system configuration. ø System Dump Configurator - System Dump configuration. ø DMI MIF Browser - Utility to display Vital Product Data (VPD) information. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.6.2 System Management Initialization Process In order to obtain the necessary information or data for systems management, OS/2 Warp Connect (PowerPC Edition) contains a system management initialization process called SMSTART. The SMSTART module is invoked by the OS/2 Server during startup of the OS/2 Warp Connect (PowerPC Edition) operating system. SMSTART is a simple program that provides the following services to the system: ø Starts a thread that handles the enablement part of the system dump. ø Creates a thread for each of the following processes and starts them in the following order: - First Failure Support Technology (FFST) microkernel service daemon - Desktop Management Interface (DMI) - Error log daemon - Trace daemon - FFST daemon These process are continuously monitored and restarted if they die. If the SMSTART process experiences problems in starting one of the processes, other than the error log daemon, then it will append the reason to the error log. If SMSTART is unable to start the error log daemon, or is having problems starting its own process, then it will log the error to an internal file (SMSTERR.DAT) on the boot drive, and in the OS2\SYSTEM\RAS directory. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.6.3 Serviceability Tools In OS/2 Warp Connect (PowerPC Edition), the serviceability tools are programs that have been supplied with the system in order to provide system management capabilities. The serviceability tools belong to several different classes, each of which provides a different level of system management information to the user. The serviceability tools architecture is layered to provide a hierarchy of tools: ø First Failure Data Capture (FFDC) - Error Logging - First Failure Support Technology (FFST) ø Data Browsing - Event Tracing - Resource Monitoring - Performance Monitoring ø System Dump ø Low Level Remote Debug Information on how to use the various tools described in this section is found in the on line book Systems Management User's Guide, in the Systems Management folder. Subtopics: 4.6.3.1 First Failure Data Capture 4.6.3.2 Data Browsing 4.6.3.3 System Dump 4.6.3.4 Low Level Remote Debug ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.6.3.1 First Failure Data Capture First Failure Data Capture (FFDC) is intended to decrease the need for the reproduction of user failures by automatically capturing the data associated with a failure as soon as it is detected. In order to accomplish this, the software modules in OS/2 Warp Connect (PowerPC Edition) have been coded in a defensive manner which allows them to detect aberrant conditions. Once such a failure is detected, key internal failure states will be logged for subsequent analysis. The primary FFDC tool is the First Failure Support Technology (FFST) which utilizes the logging service. All system logs, including the all important central error log, are created and stored in the OS2\SYSTEM\RAS directory of the boot drive. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.6.3.2 Data Browsing Data browsing allows service personnel to query and sample running systems in order to better understand the operation of those systems. Data browsing is the least invasive from of serviceability tool. It should not affect the operation of a running system. The primary data browsing tools in OS/2 Warp Connect (PowerPC Edition) support Event Tracing, Resource Monitoring and Performance Monitoring. Event Tracing: Event tracing in OS/2 Warp Connect (PowerPC Edition) has been designed to incorporate the best aspects of the currently available tracing methodologies. The trace facility has been built upon the base Event Trace capabilities of the microkernel which allows the facility to be used by the microkernel, by the microkernel services and by OS/2 applications. The event tracing facility is comprised of a number of tools. They include: ø TRACE - This utility is used to turn on and off trace points. ø TRACEFMT - This utility is used to view logged event trace data. ø TRCUST - This utility is a trace point definition tool. The event trace facility has been built on the existing OS/2 trace facility. It has been expanded to include support for the new OS/2 Warp Connect (PowerPC Edition) components (for example, the microkernel). The changes will be incorporated into the OS/2 Warp (Intel) version of the operating system. Performance Monitoring: The main tool provided in OS/2 Warp Connect (PowerPC Edition) for performance monitoring is called the System Performance Display program (SPD) for OS/2 Warp Connect (PowerPC Edition). It is designed to assist end users in analyzing system performance. The SPD helps in managing the major system resources (CPU, DASD, paging and memory) to achieve greater efficiency and maximum performance. The SPD tool allows for collecting of performance data about the operating system and applications, displaying this information graphically, and creating reports or providing statistics on the collected data. Resource Monitoring: Resource monitoring allows the user to obtain data on usage of the various system components. Since this process is tightly coupled with performance monitoring, the Systems Performance Display program contains features that allow resource monitoring to occur. For example, the SPD program, has a memory analysis tool which allows memory analysis at various levels, including the working set. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.6.3.3 System Dump It is possible that First Failure Data Capture (FFDC) will not be sufficient to solve all detected system and application problems. In some cases it will be necessary to use the broader approach of taking a full system dump. OS/2 Warp Connect (PowerPC Edition) supports an automatic system dump capability that can dump system images to a defined disk area. The system dump mechanism also has the ability to automatically reboot the system. The OS/2 Warp Connect (PowerPC Edition) system dump process consists of three parts: ø Configuration/Enablement The covers all the preparatory activities that occur before a system dump is taken. Control of this function is through the System Dump Configurator program. ø Triggering As with OS/2 Warp (Intel), the system dump can be triggered by keyboard entry sequences, programmable APIs or CONFIG.SYS entries. One difference is that the system dump is now taken by the microkernel. ø Formatting OS/2 Warp Connect (PowerPC Edition) provides a system dump formatter to display all portions of the system dump. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.6.3.4 Low Level Remote Debug When occasions occur that FFDC and System dumps do not provide enough information, OS/2 Warp Connect (PowerPC Edition) also has the ability for remote debug. The remote debugging facility is based on a core kernel-level debugger that is included in all OS/2 Warp Connect (PowerPC Edition) systems (as part of the microkernel product). The debug system can be accessed by attaching another machine to the serial port of the PowerPC machine and using the debugger through a communications program. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.6.4 Vital Product Data The Vital Product Data (VPD) facility is a new capability for the OS/2 environment. It provides a standard way in which to describe the hardware and software parts of a system. VPD information is used for a variety of purposes that include: ø Enables the creation of serviceability tools that display what components are present of a customer's system. ø Allows standard component identification information to be included on all logged error records. ø Enables the installation tools to determine the current state of product prerequisites and co-requisites on a customer's system. ø General system management. The VPD facility has been based on the Desktop Management Interface (DMI) standard, which was developed by the Desktop Management Task Force (DMTF). Subtopics: 4.6.4.1 The DMI Standard ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 4.6.4.1 The DMI Standard The DMTF DMI standard is an attempt to create a local operating system framework that links network management agents to the hardware and software components running on the system. The DMI standard addresses four levels of definition: ø An API set (called the Management Interfaces (MI)) that can be called by management applications (or their agents). ø A Logging Service Interface (SPI) set (called the Component Interface (CI)) that allows hardware and software components to respond to MI requests. ø A file-based syntax (called the Management Information Format (MIF) syntax) that allows DMI-compliant components to be defined to the DMI Service Layer (SL). ø A set of standardized group definitions that define classes of attribute sets that are shared by classes of components. The heart of the DMI architecture is the MIF database. As DMI components are installed, their MIF file definitions are installed within the MIF Database. As with a products relating to systems management in OS/2 Warp Connect (PowerPC Edition), the MIF database resides in the OS2\SYSTEM\RAS directory on the boot drive. In OS/2 Warp Connect (PowerPC Edition), access to the VPD information is through the DMI MIF Browser program. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.0 Chapter 5. Installation The OS/2 Warp Connect (PowerPC Edition) installation process has changed significantly from the current OS/2 Warp (Intel) version of OS/2. The first release of the installation program provides the ability to install the operating system, its features, device drivers, and other applications. Applications can be pure OS/2 applications, OS/2 applications with system service components, or pure system services that run on the IBM microkernel. In this release of OS/2 Warp Connect (PowerPC Edition), the Configuration Installation and Distribution (CID) methodology of installing of the operating system is not possible. However, CID installation is still available for the installing of CID enabled applications into the OS/2 Warp Connect (PowerPC Edition) environment. The OS/2 Warp Connect (PowerPC Edition) installation is described in two phases. The goal of the first phase, called media preparation, is to prepare the machine for the installation of the OS/2 Warp Connect (PowerPC Edition) system. The second phase, feature install, allows the installation of the OS/2 Server and optional features. Subtopics: 5.1 Media Preparation 5.2 Feature Install 5.3 Inventory Information 5.4 CID and Unattended Installation Support 5.5 Tracing Installation Problems ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.1 Media Preparation The media preparation phase of the OS/2 Warp Connect (PowerPC Edition) installation is similar to the initial phase of the OS/2 Warp (Intel) version of the operating system. The aim of this phase is to prepare the machine for the installation of the operating system by partitioning the hard disk into the necessary configuration. During this phase of the installation, the following sequence of events occurs: 1. Initial boot from the CD-ROM installation media. 2. Load and start the Microkernel, Microkernel Services, Shared Services, and the OS/2 installation program from the installation media. 3. Load and start the media preparation program by the OS/2 initialization program. 4. Partition the hard disk using the utility file server (FDISK). 5. Create the initial file system(s) using the utility file server (FORMAT). 6. Return to the OS/2 initialization program. 7. Load and start the OS/2 Server from the installation media with PM Shell activated. 8. Copy files of MK and OS/2. The IBM Microkernel relies on device configuration data, and resource description, to properly configure a device. Depending on the system architecture, the device configuration information is obtained from a variety of sources. Subtopics: 5.1.1 Partitioning 5.1.2 System Migration ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.1.1 Partitioning One of the main differences in OS/2 Warp Connect (PowerPC Edition) and OS/2 Warp (Intel) is the requirements for the partitioning of the hard disk. Instead of a single partition that was used in OS/2 Warp (Intel), two partitions are created OS/2 Warp Connect (PowerPC Edition). A typical example of an OS/2 Warp Connect (PowerPC Edition) disk configuration is shown in Figure 24. The two partitions are known as the: ø Boot or Type 41 Partition ø System Partition Figure 24. Disk Partitions in the Boot Device The boot partition contains the boot loader. The boot loader is a requirement by the firmware of the PowerPC and is loaded by the firmware when the system boots. The boot partition is a small partition of approximately 1-2MB. The system partition is the main partition of OS/2 Warp Connect (PowerPC Edition). It is entered into the name space as ( /file/system ) and contains the following OS/2 Warp Connect (PowerPC Edition) components: ø The Microkernel, Microkernel Services, System Services, Device Drivers and control files necessary to correctly execute the microkernel. ø The OS/2 Server and its associate support files. ø Enough space to support paging during the boot process. Once the system has started, the OS/2 Server will start an additional paging system for its own needs. In the first release of the operating system, the system partition is a primary partition, formatted using the FAT file system. There is no option during the installation to choose the file system for the system partition. HPFS formatted system partitions may be an option in a future release of the operating system.HPFS partion is supported in the user partition. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.1.2 System Migration OS/2 Warp Connect (PowerPC Edition) can be installed over any previous PowerPC based operating system. However, there are a number of restrictions in what information can be migrated to the new installation. If you are re-installing the system over a previous copy of the OS/2 Warp Connect (PowerPC Edition) operating system, then the system will migrate exiting applications and programs. If you are installing over one of the two currently available PowerPC operating systems, Windows NT (PowerPC Edition) or AIX, then no system migration occurs. In fact if the native file system of Windows NT or AIX is being used (for example the NTFS file system for Windows NT) then the hard disk must be reformatted during the first phase of the OS/2 Warp Connect (PowerPC Edition) installation. In OS/2 Warp (Intel) the boot manager facility allowed different operating systems to co-exist on the same hard disk. In this release of OS/2 Warp Connect (PowerPC Edition), a boot manager facility has not been provided. A multi-boot facility which would allow a combination of PowerPC based operating system may be available in a future release. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.2 Feature Install Feature install handles the installation of documentation, games and the BonusPak. Feature install also handles maintenance of software in that same way that it handles new software installation. This means that unlike in OS/2 Warp (Intel) a separate service installation tool is not necessary. Although the new installation routines will allow for cumulative and selective fixes to be applied to the system, for the first release of the OS/2 Warp Connect (PowerPC Edition) operating system, backout of service installations is not supported. Subtopics: 5.2.1 Feature Install Catalog 5.2.2 Drag and Drop Install 5.2.3 Install Objects 5.2.4 Inventory Objects ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.2.1 Feature Install Catalog The first screen that is shown during the installation is the Feature Install catalog. Not unlike the selective install program in OS/2 Warp (Intel), the Feature Install program allows you to choose to install documentation, games and BonusPak. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.2.2 Drag and Drop Install One of the most innovative features of the feature installation program is that each feature that is installed is considered an object by the system. This is totally different to the OS/2 Warp (Intel) installation program and allows a level of configurability that was unavailable in previous OS/2 versions. In order to accomplish this, the feature installation program adds two objects to the Workplace Shell environment. They are: ø Install Object ø Inventory Object Both of these objects have settings that can be changed by the user. The install objects can be opened to make selections and configuration changes, while the inventory objects contain information about system software installed in the system. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.2.3 Install Objects The install object represents a product that can be installed to your system. The object exists on the product source media, and can be accessed through the file system object. For example, a product that is shipped on CD-ROM could be represented by an install object in the root directory of the CD-ROM. In this case, the user could view the product's install object by placing the CD-ROM in the drive and selecting Open - icon view from the context menu of the CD-ROM drive object. The install object would be visible alongside any file objects in the top container of the opened CD-ROM object. For OS/2 Warp Connect (PowerPC Edition), the existence of the install object allows you to bypass the Feature Install catalog and install the various components directly from the install object. The install object class supports commonly used installation functions (such as file copy, configuration file updating, and product registration). Once the install object is visible, you may install all defaults for the product by simply dragging the install object to any Workplace Shell folder, including the desktop itself. Alternatively, you could perform actions on the install object to configure the product before installation. From the install object context menu, the user can open a tree view of the object (to obtain access to a lower level of install objects) or open the object settings (to view product information). Subtopics: 5.2.3.1 Available Modes ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.2.3.1 Available Modes Install objects support two different modes of operation. They are: ø Development ø User Development mode enables the creation of install objects. This mode is used by software developers. User mode allows for the installation of install objects. This mode is used by the end user. For example, the end user should not be able to modify the information on the install object settings pages. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.2.4 Inventory Objects An inventory object represents a product that has been installed to the your system. This object may be used to remove the product the product from the system (uninstall), or simply to view the features and settings that were selected when the product was installed. One advantage of the inventory objects is for CID administrators. Each inventory object provided by the Feature Installer stores its persistent data in an associated text file called INSTDATA.INI. This file contains the CID keywords that were used to create the object. This means that creating a CID response file merely involved copying the information from the INSTDATA.INI files to a new response file. Subtopics: 5.2.4.1 Views 5.2.4.2 Removing Features 5.2.4.3 Adding Features to the System ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.2.4.1 Views The inventory hierarchy parallels the hierarchy of install objects that were selected when the product was installed. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.2.4.2 Removing Features The inventory objects offer greater control over removing operating system features than was available in OS/2 Warp (Intel). In order to remove a feature from the system, simply drag the inventory object representing the installed product to the shredder, or by selecting uninstall from the open view or from the objects context menu. This will result in the deletion of the product files, the reversal of any configuration changes made when the product was originally installed, the deletion of any workplace objects created for the product, and the deletion on the products inventory object. The Inventory objects are kept in an Installed Software folder. The Installed Software folder is available from the OS/2 desktop. Although this system is somewhat more powerful than the uninstall feature of OS/2 Warp (Intel), it does not support the removal or the entire operating system. If you wish to install a different operating system onto the machine, then the most common practice is still to use FDISK and FORMAT, in the same way that OS/2 Warp (Intel) is working currently. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.2.4.3 Adding Features to the System Adding additional features once a component is installed is very easy. To add features or components that were not originally selected simply follow one of the steps outlined below: ø Re-open the install object and drag the desired subfeature to the corresponding inventory object. ø Select install from the context menu for the feature. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.3 Inventory Information Documentation of what is installed on the system, and the level of the software on the system is maintained in an installed software inventory. This ensures that service applied to the system will not return the user to a previous level of the software. Using the installed software inventory, also provides service with an accurate description of products and services installed onto a machine. This makes it easier for service to give a customer a response to his problem, and it gives service the ability to more accurately duplicate a customer's system for problem re-creation. The following information is recorded in an installed software inventory about each product subproduct installed: ø Description - A description of the software. ø Tag - A short name for the software. ø Title - The software package title. ø VendorTag - A short name for the software manufacturer. ø VendorTitle - The name of the software manufacturer. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.4 CID and Unattended Installation Support All of the installation programs and mechanisms in OS/2 Warp Connect (PowerPC Edition) support the Configuration, Installation, and Distribution (CID) architecture which calls for support of installation from redirected sources and installation in an unattended fashion. This entails: ø Redirected installation ø Response file support ø Ability to transfer product files / images to a code servers hard disk for installation purposes ø Command line support is implemented via Clifi executable ø Logged process information In this release of the OS/2 Warp Connect (PowerPC Edition) operating system, CID support differs slightly from what is available in OS/2 Warp (Intel). Although it is still possible to install applications and fixes using the CID methodology, the operating system itself cannot be installed using CID. Subtopics: 5.4.1 Standard Keywords ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.4.1 Standard Keywords The following standard keywords are supported by the OS/2 Warp Connect (PowerPC Edition) Feature Installer: ø Include - Include other response files for processing ø Reinstall - Force reinstallation, even if the product is up to date (Implemented only through Clifi). ø Append - Append log information to log files (Implemented only through the Clifi). Several of the commonly used keywords are no longer supported by the OS/2 Warp Connect (PowerPC Edition) Feature Installation program, and are shown in Table 7. ______________________________________________________________________________________________________________________ | Table 7. Unsupported CID Keywords in OS/2 Warp Connect (PowerPC Edition) | |_____________________________ _____________________________ __________________________________________________________| | Keyword | Definition | Comment | |_____________________________|_____________________________|__________________________________________________________| | Copy | Copy a file. | This keyword will be ignored by the OS/2 Warp Connect | | | | (PowerPC Edition) Feature Installer | |_____________________________|_____________________________|__________________________________________________________| | UserExit | Execute a user exit | This keyword will be ignored by the OS/2 Warp Connect | | | program. | (PowerPC Edition) Feature Installer. The Installer | | | | provides a rich ability for a package developer to | | | | specify user exits. | |_____________________________|_____________________________|__________________________________________________________| | Reconfigure | Force product | The OS/2 Warp Connect (PowerPC Edition) Installer does | | | reconfiguration. | not separate the file transfer and configuration steps. | | | | Configuration will always be done. | |_____________________________|_____________________________|__________________________________________________________| | Software | Identify product features. | This keyword will be ignored by the OS/2 Warp Connect | | | | (PowerPC Edition) Feature Installer. | | | | | | | | The Installer uses a SELECTED variable for each object | | | | that is to be installed. The value of this variable can | | | | be changed by the actions that occur as a result of | | | | processing dependencies that the package developer | | | | specified. | | | | | | | | Within the appropriate sections of the response file the | | | | SELECTED keyword my be used to selected the installation | | | | of specific software. Dependency processing will | | | | override any setting specified in the response file. | |_____________________________|_____________________________|__________________________________________________________| | Defer_Configure | Defer product | This keyword will be ignored by the OS/2 Warp Connect | | | configuration. | (PowerPC Edition) Feature Installer. | |_____________________________|_____________________________|__________________________________________________________| | Icon_Placement | Specify positioning of | This keyword will not be produced or directly processed | | | product icons within a | by the OS/2 Warp Connect (PowerPC Edition) Installer. | | | folder. | However, it will be parsed and made available to product | | | | developers within user exists. If included in a | | | | response file, it needs to be placed in the appropriate | | | | section. When name qualification will not remove an | | | | ambiguity, only the last one encountered will be | | | | remembered. | | | | | | | | This function is handled via the Create Objects pages | | | | through the setup string parameter. Variables can be | | | | used within the setup string to control the icon | | | | placement. | |_____________________________|_____________________________|__________________________________________________________| | Folder_placement | Specify positioning of | This keyword will not be produced or directly processed | | | product folders. | by the OS/2 Warp Connect (PowerPC Edition) installer. | | | | However, it will be parsed and made available to product | | | | developers within user exists. If included in a | | | | response file, it needs to be placed in the appropriate | | | | section. When name qualification will not remove an | | | | ambiguity, only the last one encountered will be | | | | remembered. | | | | | | | | This function is handled via the Create Objects pages | | | | through the setup string parameter. Variables can be | | | | used within the setup string to control the folder | | | | placement. | |_____________________________|_____________________________|__________________________________________________________| ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.5 Tracing Installation Problems One of the most common problems with OS/2 Warp (Intel) was with the installation of the product. Users were often left with a system that has failed to install, but without any indication to what portion of the installation failed. In order to rectify at least some of this problem, OS/2 Warp Connect (PowerPC Edition) supports the use of First Failure Support Technology (FFST) for error logging during the installation. It also uses FFST for its data browsing capabilities to externalize the relevant state of the component, both during system boot from a CD-ROM and during selective installation of subsystems. Externalizing the state of a component allows the user to examine what action the component was performing when it may have failed. FFST error logging is always enabled. The default error log is kept in the install target partition during a CD-ROM boot, unless otherwise specified in the response file. In this case, the response file would be located on diskette. In addition to the FFST support, the OS/2 Warp Connect (PowerPC Edition) Install component keeps a user-defined error and activity log independent of FFST in order to meet CID requirements. Subtopics: 5.5.1 Media Preparation 5.5.2 Feature Install ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.5.1 Media Preparation Only a limited number of error messages can be logged using First Failure Support Technology (FFST) before the OS/2 server is running. During the media preparation, OS/2 Warp Connect (PowerPC Edition) uses one FFST call to indicate an error has occurred and direct the user to the more detailed install error log, called INSTALL.LOG, which is kept in the target partition. Entries will be recorded in the install log for the following: ø Error Messages - For errors detected during media preparation and the formatting of partitions ø Major System Changes - Such as disk partitioning and formatting of partitions ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 5.5.2 Feature Install Due to the object oriented and graphical nature of the Feature Installation component, much of the internal state of the installation has already been externalized. For example, feature selection and dependencies, variable resolution, and file lists are already accessible to the user and support personnel. The OS/2 Warp Connect (PowerPC Edition) Feature Installation component provides the following information through FFST: 1. Procedure tracepoints. Major functions are traced to provide sufficient information to understand component failures. a. File transfer functions 1) Source and target filenames, including path b. Object creation and class registration 1) Setup string used to create the object 2) Setup string used to register the class c. Configuration changes to CONFIG.SYS, OS/2 and Windows INI files 1) Lines deleted 2) Lines added 3) Lines modified d. User Exit APIs 1) Feature ID 2) Function called 2. Error Messages. Error messages detailing component failure are logged with FFST, as well as with a user-selected log file for CID purposes. a. Configuration change errors b. File transfer c. Internal install functions d. Object creation ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 6.0 Chapter 6. Application Support OS/2 Warp Connect (PowerPC Edition) runs 32 bit OS/2 applications, and DOS, Windows or DPMI applications. It is also able to run Win32s applications as OS/2 Warp (Intel) does. The 32 bit OS/2 applications, if currently available on OS/2 Warp (Intel), need to be recompiled for the PowerPC platform. The DOS, Windows or DPMI applications run unchanged from the OS/2 Warp (Intel) environment. OS/2 Warp Connect (PowerPC Edition) provides the necessary emulation of Intel instructions to run the DOS, Windows or DPMI binaries. OS/2 Warp Connect (PowerPC Edition) will not run 16 bit OS/2 applications, nor will it run family API (FAPI) applications. Subtopics: 6.1 Application Development ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. 6.1 Application Development Currently, application development is done by the means of the Metaware cross platform development tools. This means that the compile and link of a program is done on the Intel platform, and that the executable program or dynamic library produced, has to be run on the PowerPC platform. The main components of the Metaware toolkit are: ø HCOPPC - The Compiler The compiler may be directed to invoke the other necessary components of the toolkit. If so, it creates PowerPC assembler statements and invokes the PowerPC assembler. The compiler must be on, or beyond Release 2.6. ø ASPPC - PowerPC Assembler The assembler creates an ELF compatible object file from either a source file created by the compiler or a source file written by a developer. The assembler must be on, or beyond Release 1.74. ø LDPPC - The Linker The linker may be invoked by the compiler, or it may be run separately. In both cases it links any ELF compatible object modules, regardless of their source origin, and creates an ELF executable or dynamic link library. The linker must be on, or beyond Release 3.47. ø ARPPC - The ELF Archiver The archiver manages library files by combining .OBJ files or .LIB files into new .LIB files, deletes entries in .LIB files and lists entries in .LIB files. ø ELFDUMP - The ELF Dumper The ELF dumper knows the ELF format, and presents the contents of an ELF compliant file in readable form. ø BD - The Binary Dumper The binary dumper is a hexadecimal browser, which might be instructed to recognize certain data structures. The toolkit also contains documentation in the form of postscript files. It contains the necessary header files, both the standard C and C++ header files, and the OS/2 header files normally found in the OS/2 toolkit. The .LIB files associated with the above mentioned header files are present, as well as some sample programs. Finally, Direct-to-Som is supported in the package. ¸ Copyright IBM Corp. 1995 - IBM BookManager BookServer Copyright 1989, 1996 IBM Corporation. All rights reserved. A.0 Appendix A. Changes to MVM DOS Settings ______________________________________________________________________________________________________________________ | Table 8. Changes to the MVM DOS Settings. | |__________________________________________________ __________________________________________________ _____ _____ ____| | | | | | | | | | | | | | | | Adde| Dele|eCha|ged | | | | | | | DOS Setting | Description | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | COM_DIRECT_ACCESS | In OS/2 Warp Connect (PowerPC Edition), direct | | | | | | access to hardware applications is not permitted | | | | | | by the hardware. Consequently, OS/2 Warp | | &che|k. | | | Connect (PowerPC Edition) will always emulate | | | | | | application access of hardware ports. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DOS_BUFFERS | Comparable to the BUFFERS= statement in PCDOS, | | | | | | which is used to allocate memory for a specified | &che|k. | | | | number of disk cache buffers when the system | | | | | | starts. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DOS_CODEPAGE | This setting allows the user to specify the | | | | | | codepage of a DOS session. The codepage must be | &che|k. | | | | already available in the system, allowing the | | | | | | user to choose from an available list. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DOS_COUNTRY | This setting allows the user to specify the | | | | | | country code for a DOS session. The country | | | | | | code must be already available in the system, | &che|k. | | | | allowing the user to choose from an available | | | | | | list. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DOS_FCBS | This DOS settings is carried over from OS/2 Warp | | | | | | (Intel), but the defaults have changed from | | | | | | those used by OS/2 Warp (Intel). This setting | | | | | | is used to specify the maximum number of FCBs | | | | | | (file control blocks) that can be open | | | &ch|ck. | | concurrently in one DOS session. One of the two | | | | | | possible parameters on this setting has been | | | | | | removed; the default has been changed from 16 to | | | | | | 4. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DOS_FCBS_KEEP | Under OS/2 and versions of DOS prior to 6.3, | | | | | | there are two FCB values. The second value is | | &che|k. | | | no longer utilized, meaning that this entry is | | | | | | no longer required. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DOS_INSTALL | Loads a memory-resident program into memory when | | | | | | you start a DOS session. The memory-resident | | | | | | programs stay in memory as long as your sessions | &che|k. | | | | exist, and can be used even when other programs | | | | | | are active. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DOS_MESSAGE_FILE | This setting specifies the language that will be | &che|k. | | | | used for a session. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DOS_NUMLOCK | This setting specifies whether the NUM Lock key | | | | | | on the keyboard is set to ON or OFF when the VDM | &che|k. | | | | starts. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DOS_STACKS | This setting supports the dynamic use of stacks | | | | | | to handle hardware interrupts. | | | | | | | | | | | | STACKS=n,s. n specifies the number of stacks. | | | | | | Valid values for n are 0 and numbers in the | &che|k. | | | | range 8 through 64. s specifies the size (in | | | | | | bytes) of each stack. Valid values for s are 0 | | | | | | and numbers in the range 32 through 512. The | | | | | | default for this setting is 9,128. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DOS_SWITCHES | This setting provides special options, useful | | | | | | only from the config.sys file. The options are: | | | | | | | | | | | | ø /K, forces an enhanced keyboard to behave | | | | | | like a conventional keyboard. | | | | | | | &che|k. | | | | ø /N, prevents you from using the F5 or F8 key | | | | | | to bypass startup commands. | | | | | | | | | | | | ø /F, skips the delay after displaying the | | | | | | 'Starting PC DOS...' message during startup. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | DPMI_DOS_API | The default for this setting has changed from | | | &ch|ck. | | AUTO to ENABLED. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | EMS_LOW_OS_MAP_REGION | This setting was designed specifically to | | | | | | support Microsoft Windows Version 2.0 real mode | | | | | | applications. OS/2 Warp Connect (PowerPC | | &che|k. | | | Edition) will not support Windows 2.0 | | | | | | applications. Hence, this setting is no longer | | | | | | required. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | GENERIC_HW_SUPPORT | This setting allows the user to specify if they | &che|k. | | | | want support for generic devices or not. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | HW_ROM_TO_RAM | | | | &ch|ck. |__________________________________________________|__________________________________________________|_____|_____|____| | IDLE_MAX_SLEEP_TIME | This setting defines the maximum period of time, | | | | | | in milliseconds, that the DOS session will be | | | | | | put to sleep when it is determined that the DOS | | | | | | session is idle. A value of 0 will disable the | &che|k. | | | | idle detection in this DOS session. | | | | | | | | | | | | The default setting is 2000 milliseconds. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | IDLE_SENSITIVITY | In OS/2 Warp (Intel), this setting was used to | | | | | | set a threshold for polling time before the | | | | | | operating system reduced the polling programs | | | | | | portion of the processor time. | | | | | | | | &che|k. | | | This setting has been replaced by: | | | | | | | | | | | | ø IDLE_TIMEOUT | | | | | | | | | | | | ø IDLE_MAX_SLEEP_TIME | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | IDLE_TIMEOUT | This setting defines the amount of time (in | | | | | | seconds) allowable between the last busy event | | | | | | and an idle event. A value of 0 will disable | &che|k. | | | | idle detection in this DOS session. | | | | | | | | | | | | The default value is 5 seconds. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | TRANSLATED_CACHE_SIZE | This setting allows the user to specify the size | &che|k. | | | | of the Intel translated instruction cache. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | VIDEO_FASTPASTE | This setting exists in OS/2 Warp (Intel). Its | | | | | | purpose is to allow applications to receive | | | | | | pasted data from the DOS shield via an INT 16 | | | | | | fast path that bypassed much of the processing a | | | | | | normal INT 9 paste enabled. | | | | | | | | | | | | OS/2 Warp Connect (PowerPC Edition) has a | | | | | | built-in mechanism that allows pasted characters | | | | | | to feed to the application key buffer as fast as | | &che|k. | | | the application can retrieve them without | | | | | | overlaying the previous unretrieved characters. | | | | | | | | | | | | Consequently, OS/2 Warp Connect (PowerPC | | | | | | Edition) provides the same function, in the form | | | | | | of a continuous built-in feature while supplying | | | | | | additional function that prevents pasted | | | | | | keystrokes from being overwritten. Hence, this | | | | | | setting is not required. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | VIDE0_8514A_XGA_IOTRAP | In OS/2 Warp (Intel), this setting was set to ON | | | | | | to allow controlled access to the video device. | | | | | | It was set to OFF to provide faster unrestricted | | | | | | access for games and graphical applications. | | &che|k. | | | | | | | | | IO trapping in OS/2 Warp Connect (PowerPC | | | | | | Edition) has to be done at all times, so there | | | | | | is no need for this foreground performance item. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | VIDEO_ONDEMAND_MEMORY | This setting was meant to be a way of increasing | | | | | | the speed of the session switch by allocating | | | | | | the shadow VRAM as the access to the physical | | | | | | VRAM was taking place. | | | | | | | | &che|k. | | | This setting is no longer supported as it is not | | | | | | clear whether the user can measure the benefits | | | | | | of such a feature or decide if an application | | | | | | would be more usable if the property is set. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | VIDEO_RETRACE_EMULATION | This property was meant to improve the | | | | | | performance of the text VRAM updates by | | &che|k. | | | emulating the video retrace. This had an | | | | | | adverse effect on the graphical applications. | | | | |__________________________________________________|__________________________________________________|_____|_____|____| | VIDEO_VRAM_USAGE | This setting controls how the off-screen usage | &che|k. | | | | is handled for the DOS sessions. | | | | |__________________________________________________|__________________________________________________|_____|_____|____|