Virtual Device Driver Reference for OS/2
By IBM
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation
About This Book
The OS/2 Virtual Device Driver Referencedefines what a virtual device driver is, how it operates, and when to use one. In addition, a description of the types of virtual device drivers, their interfaces, and the available kernel services is provided. System and application programmers can use the information found in this book to write their own virtual device drivers and subsystems.
Knowledge of a programming language (such as C or assembler) that is used for writing OS/2 applications is necessary, and the programmer must be familiar with the workings of the OS/2 operating system.
How This Book is Organized
This book consists of three parts:
Part 1. Overview
- Introduction
- This chapter contains a general description of the three types of OS/2 device drivers, and an overview of the virtual device driver mechanism and kernel services.
Virtual Device Driver Architecture and OperationsThis chapter contains a description of virtual device driver architecture, operations, and communication between device drivers.
Part 2. Virtual Device Drivers
Base Virtual Device DriversThis chapter contains a description of each base virtual device driver shipped with OS/2.
Installable Virtual Device DriversThis chapter contains a description of each installable virtual virtual device driver shipped with OS/2.
Virtual Mouse Device DriverThis chapter describes the virtual mouse device driver (VMOUSE), which is responsible for all mouse support in multiple DOS sessions.
Part 3. Reference Material
C Language Virtual DevHlp ServicesThis chapter contains full C language descriptions of the kernel functions available to virtual device drivers.
Appendixes
- OS/2 Version Compatibility Considerations
- This table describes information added to or changed since the availability of OS/2 Warp, Version 3 in terms of version compatibility.
- Assembler Language Syntax
- This appendix contains assembler language versions of the kernel functions covered in Chapter 6.
- Notices
- This appendix contains legal notices and lists the trademarks of the IBM Corporation and trademarks of other companies.
A glossary and an index are included at the back of this book.
Assistance
Technical support for device driver development is provided by the IBM Driver Development Support Center (DDSC) through a bulletin board system ( BBS) known as the "DUDE." You are encouraged to use the DUDE to obtain support by sending in your questions and reviewing the question and answer database which can be downloaded for off-line review.
To access the DUDE, dial 512-838-9717 (using a modem) to register and access the support system. For voice support in the United States, call 512 -838-9493.
Additional assistance is available through the IBM Solution Developer Program. For membership information:
Internet: ibmsdp@vnet.ibm.com
US/Canada: 800-627-8363
International: 770-835-9902
International Fax: 770-835-9444
Ordering Information
For an illustration of OS/2 Technical Publications and other related product documents, see the figure labeled "OS/2 Technical Publications". The documents represented in this illustration are available only in English.
In addition to the actual tools and source code available on The IBM Developer Connection Device Driver Kit for OS/2, this CD-ROM also includes the following DDK reference books in online format.
- The Physical Device Driver Reference
- The Storage Device Driver Reference
- The Input/Output Device Driver Reference
- The Pen for OS/2 Device Driver Reference
- The Virtual Device Driver Reference
- The Presentation Device Driver Reference
- The Display Device Driver Reference
- The Printer Device Driver Reference
- The Graphics Adapter Device Driver Reference
- The MMPM/2 Device Driver Reference (Multimedia)
To order the DDK call:
/----------------------------------------------------------------\ |U.S.A.: |1-800-633-8266 | | |--------------------+---------------------+---------------------| |Canada: |1-800-561-5293 | | |--------------------+---------------------+---------------------| |When calling from |* English |(+45) 48101500 | |Europe, the Middle |* French |(+45) 48101200 | |East, or Africa, the|* Italian |(+45) 48101600 | |number depends on |* German |(+45) 48101000 | |the language you use|* Spanish |(+45) 48101100 | |to place the order: |* Dutch |(+45) 48101400 | | |* Danish |(+45) 48101300 | | |* Finish |(+45) 48101650 | | |* Swedish |(+45) 48101150 | | |* Norwegian |(+45) 48101250 | | |* FAX |(+45) 48142207 | |--------------------+---------------------+---------------------| |When ordering from |* Bolivia | 02-35 1840 | |Latin America or |* Columbia | 01-257-0111 | |South America, the |* Dominican Republic | 566-5161 | |number depends on |* El Salvador | 02-98 5011 | |the country from |* Honduras | 32-2319 | |which you are |* Paraguay | 021-444 094 | |calling: |* Urugruay | 02-923 617 | | |* Chile | 02-633-4400 | | |* Costa Rica | 223-6222 | | |* Ecuador | 02-56 5100 | | |* Guatemala | 02-31 5859 | | |* Panama | 02-639 977 | | |* Peru | 014-36 6345 | | |* Venezuela | 02-908-8901 | | |* Argentina | 01-313-0014 | |--------------------+---------------------+---------------------| |To order from Asia/ |* All except Japan |(61) 2-354-7684 | |Pacific: |* Japan |(81) 3-3495-2045(Fax)| | | |Fax request to: | | | |DAP-J, IBM Japan | |--------------------+---------------------+---------------------| |To order from SE |(021) 800-6120(Voice)| | |Brazil: |(021) 800-6936(Fax) | | |--------------------+---------------------+---------------------| |To order from |* Mexico City |627-2444 | |Mexico: |* Country |91-800-00639 | \----------------------------------------------------------------/
What's New
Following is a list of the changes made to the OS/2 Virtual Device Driver Reference(Fourth Edition) since it was published in April 1995.
Refer to OS/2 Version Compatibility Considerationsfor a table listing compatibility information about new information in this book.
Introduction
Virtual device drivers are used by the OS/2* operating system to act as virtual devices for DOS applications executing in a DOS session. These device drivers provide virtual hardwaresupport for DOS and DOS applications.
The virtual device drivers shipped with OS/2 will virtualize most of the standard devices, including:
- Asynchronous Communication (RS-232C)
*DMA (Direct Memory Access)
*Fixed Disk and Diskette
*Keyboard
*Mouse
*Parallel Port Printer
*PIC (Programmable Interrupt Controller)
*Timer
*Video
This book provides an overview of the virtual device driver mechanism and the available kernel services.
Types of OS/2 Device Drivers
Three types of device drivers are used in the OS/2 operating system:
- Virtual device drivers
*Physical device drivers
*Presentation drivers
Virtual Device Drivers
The virtual device driver is an installable module, responsible for virtualizing a particular piece of hardware and associated ROM BIOS in the manner expected by a DOS application. This device driver achieves virtualization by emulating I/O port and device memory operations. Virtual device drivers are 32-bit device drivers, operating at Ring 0, the most privileged level of the operating system. To achieve a certain level of hardware independence, a virtual device driver usually communicates with a physical device driver in order to interact with hardware.
Physical Device Drivers
Standard I/O devices are supported by base physical device drivers that are part of the OS/2 operating system. Additional or replacement physical device drivers can be loaded to extend the control provided by the base device drivers, or to support nonstandard I/O devices. Typical examples of these loadable device drivers are ANSI.SYS and ANSI.DLL, which are loaded by "DEVICE=" statements in the CONFIG.SYS file, and provide additional functions on the interfaces to the screen and keyboard. Physical device drivers are initialized at Ring 3 and operate at Ring 0.
Further information on physical device drivers, physical device driver interfaces (including detailed descriptions of the calling conventions), and the system services available to these drivers is found in the OS/2 Physical Device Driver Reference.
Presentation Drivers
The Presentation Manager* I/O interface for output devices is a high-level interface. This interface is similar to the API (Application Programming Interface) call interface, which uses the program stack to communicate with , or pass parameters to, the presentation drivers. These drivers are special-purpose I/O routines operating with I/O privilege at privilege level 2 (Ring 2) or privilege level 3 (Ring 3). Their main function is to process function calls made by the Presentation Manager interface on behalf of Presentation Manager applications. Hardcopy presentation drivers communicate with OS/2 device drivers through the file system emulation functions. Display presentation drivers interface directly with the hardware.
Presentation drivers are dynamic link library modules that are supplied as files and are identified by the extension ".DRV". When the Presentation Manager is initialized, the display presentation driver is automatically loaded and enabled. Other presentation drivers (for example, the hardcopy presentation drivers) are loaded and enabled when an application calls the DevOpenDCfunction to open the device.
Presentation drivers service requests only from applications running in Presentation Manager sessions in the OS/2 mode. Output data and requests for information are passed to the presentation driver as function calls to the presentation driver interface. The definition of the call interface is given in terms of the codes and data passed to the presentation driver interface through the program stack.
Include (.INC and .h) files are shipped with the Developer's Toolkit for OS /2to provide support for building presentation drivers that are written in either C or assembler language. These files contain function prototypes, defined values, and data structures used by the various functions.
Further information on presentation drivers, presentation driver interfaces (including detailed descriptions of the calling conventions), and the system services available to these drivers is found in the OS/2 Presentation Device Driver Reference.
When to Use a Virtual Device Driver
The device virtualization provided by OS/2 can be extended by creating a virtual device driver (VDD) and the corresponding physical device driver ( PDD). A user-supplied virtual device driver virtualizes the hardware interfaces of an option adapter or device, usually to migrate an existing DOS application into the OS/2 DOS environment.
Note that a virtual device driver is needed only in a limited number of cases. If there is no requirement for multiple sessions to share access to a device, a requirement for a virtual device driver is unlikely. OS/2 maps interrupts, I/O ports, and I/O memory directly to any DOS device driver or DOS application which attempts to access these resources. As long as a resource is not already claimed by another session or by the OS/2 kernel, it is directly accessible to the DOS program.
Where access-sharing is required, it is generally not necessary to create a virtual device driver if the I/O is handle-based. DOS INT 21h I/O requests are routed by the OS/2 file system to the protect-mode physical device driver. If all I/O is handle-based, it is necessary only to create the physical device driver.
For block devices, it is recommended that OS/2 support be provided only by a physical device driver. Both DOS and OS/2 sessions will then access the device through file system interfaces defined by DOS and the OS/2 operating system.
In the absence of a sharing requirement, a virtual device driver might be necessary if the device has strict interrupt service latency requirements. A virtual device driver/physical device driver pair improves the interrupt service latency for an option adapter or device.
Virtual Device Driver Architecture and Operations
The architecture and structure of virtual and physical device drivers differ considerably from one another. A physical device driver is considered a true device driver in the sense that it has a unique and rigid file structure, and interfaces directly with the hardware. A virtual device driver is essentially a dynamic link library, and generally does not interface directly with the hardware. Instead, it is responsible for presenting a virtual copy of a hardware resource to a DOS session, and for coordinating physical access to that resource.
Virtual Device Driver Architecture
Virtual device drivers manage I/O ports, device memory, and ROM BIOS services for the devices they virtualize. For hardware compatibility purposes, a virtual device driver should behave as much as possible like the physical hardware. Otherwise, incompatible emulation could result. In the case of system drivers, a virtual device driver should use a physical device driver to manipulate hardware, wherever possible.
Virtual Device Driver Structure
A virtual device driver is a 32-bit EXE file that may contain some or all of the following types of objects:
- Initialization code
*Initialization data
*Swappable global code
*Swappable global data
*Swappable instance data
*Resident global code
*Resident global data
*Resident instance data
The resident objects must be used for code and data that must be accessible at physical hardware interrupt time, that is, when a physical device driver calls the virtual device driver. A virtual device driver that does not interact with a physical device driver may not need any resident objects.
Virtual device drivers conform to the EXE32 Load Module format. A typical virtual device driver has a shared (global) code object, a shared (global) data object, and a private (instance) data object. It is possible for a virtual device driver to have multiple objects of each type. The global code and data objects are addressable in all process contexts. As with instance data for dynamic link libraries, the instance data object is per- DOS session data; that is, the same address in each DOS session context is initialized to the same initial state, but backed by different physical memory. Each object must be equal to or less than 64KB in size.
Run-time allocated memory can be allocated as either swappableor fixed. In addition, run-time allocated memory can also be:
- Private (per-DOS session), which is allocated out of the DOS session private memory area. This is the preferred method, and is suitable when memory is used only in the context of owning the DOS session.
*Shared (global), which is allocated from the system area. This should be used only when the allocation must be created, modified, or freed in an arbitrary process context.
Virtual Device Driver Operations
Virtual device drivers are loaded and initialized before the shell is started, but after all the physical device drivers have been loaded and initialized.
Virtual Device Driver Loading
After the physical device drivers have been loaded, the DOS Session Manager is initialized (at OS/2 system initialization time), which then initializes the 8086 emulation component, and loads and initializes the virtual device drivers. An initial V86-mode memory map is constructed at this time for later use at DOS session creation.
The DOS Session Manager calls the loader to load virtual device drivers. Base virtual device drivers are loaded first, followed by installable virtual device drivers. Basevirtual device drivers are those that must be present for multiple DOS sessions to function. Installablevirtual device drivers are those specified in the "DEVICE=" lines in the CONFIG.SYS file. The multiple DOS session environment is still operable if any or all of these installable drivers fail to load. The one exception to this rule is the virtual video device driver, which is a base virtual device driver that is loaded in the CONFIG.SYS file.
The global code and data objects are loaded into the system area. This is required so that a physical device driver can pass along a hardware interrupt by calling a virtual device driver at interrupt time, regardless of the current process context.
The instance data objects are loaded into the address space between 1MB and 4MB for that session. This is the private address space managed by the DOS session. The loader and DOS Session Manager cause this allocation to occur so that the full virtualstate of the DOS session is contained below the 4MB line, thus allowing a single Page Directory Entry (PDE) to map a DOS session context. This has two benefits:
- Context-switching DOS sessions are fast, because only a single PDE needs to be edited.
- It is simple to maintain an alias region in the system area for each DOS session. This alias region is a 4MB-aligned, 4MB region of linear address space, whose base is called a DOS session handle, which can be used in a base register to manipulate the instance data of that DOS session. This is an important feature, as it allows virtual device drivers to quickly access the instance data of any DOS session.
The virtual device driver entry point is called after the virtual device driver is loaded. The device driver returns a nonzero value to indicate a successful load, and returns 0 to indicate an unsuccessful load.
Virtual Device Driver Initialization
After a virtual device driver is loaded, it performs the following operations, as appropriate:
- Verifies the presence of corresponding hardware
*Establishes communication with the corresponding physical device driver
*Reserves regions of linear memory containing device ROM and RAM
*Saves the initial physical device state for initializing the virtual device state upon DOS session creation
*Set hooks for various DOS session events (creation, termination, foreground/background switch). See VDHInstallUserHookfor a complete list of user hooks.
Virtual device drivers are initialized at Ring 0. For this reason, they cannot make Ring-3 API calls, and they only interact with OS/2 through use of the virtual DevHlp services.
Installing User Hooks
Each virtual device driver must use VDHInstallUserHookto install a VDM_ CREATE hook. Virtual device drivers that use foreground and background (for example, video, keyboard, or mouse) must also install VDM_FOREGROUND and VDM_BACKGROUND hooks. For more information, see VDHInstallUserHook.
Allocating Global Resources
Global resources are allocated at this time.
Registering Virtual Device Driver for Communications
When virtual device drivers communicate with the kernel, physical device drivers, other virtual device drivers, or with the Presentation Manager interface, the Dynamic Link mechanism is used to:
- Export virtual DevHlp services to virtual device drivers
*Export kernel data to virtual device drivers
*Export services from one virtual device driver to another
To restrict the modifications required for physical device drivers (which remain 16:16), virtual DevHlp services are provided so that a virtual device driver can establish communication with a physical device driver. This is no more than an exchange of entry points. At this point, the physical device driver and the virtual device driver can use any protocol to communicate. Although a suggested protocol is provided in Inter-Device- Driver Communication, device drivers are not restricted to this.
DOS Session Creation and VDD Per-DOS Session Initialization
When the user starts a DOS application, the DOS Session Manager notifies the virtual device drivers that have registered creation hooks, and gives them an opportunity to do per-DOS session initialization. Memory is allocated and mapped into the V86-mode address space, and the DOS Emulation code is initialized. Control is passed to the DOS Emulation kernel to load the shell specified by DOS_SHELL (usually COMMAND.COM) and the application selected by the user.
Virtual device drivers perform the following operations (as appropriate) at DOS session creation time:
- Initialize the virtual device state
*Initialize the virtual ROM BIOS state
*Map linear regions (reserved at virtual device driver initialization time) to physical or linear memory
*Hook the I/O ports
*Enable or disable the I/O port trapping
*Hook the software interrupts
*Allocate per-DOS session memory
DOS Session Screen Switching
The OS/2 Session Manager notifies the DOS Session Manager of screen switches. The DOS Session Manager, in turn, notifies all virtual device drivers that are involved in these events (generally, the video, keyboard, and mouse virtual device drivers). The virtual video device driver (VVIDEO) takes appropriate steps to map in physical or logical video RAM and disable or enable I/O port trapping for the video hardware. The virtual keyboard device driver (VKBD) can set flags to control the reaction to keyboard polling behavior.
DOS Session Destruction
When a user exits a DOS session, the virtual device drivers are notified to clean up any resources owned by that DOS session (that is, the virtual device driver's DOS session termination entry points are called by the DOS Session Manager). Memory is released and the process is terminated, as is done with a normal OS/2 process. DOS sessions can also be terminated by a virtual device driver if unsupported behavior is detected, or by the DOS emulation component (if it is damaged or is otherwise unable to function).
Local and Global Information Regions
Most of the information available through information segments can be obtained by a virtual device driver using the virtual DevHlp service VDHQuerySysValue. For further information, see VDHQuerySysValue.
Virtual DevHlp (VDH) Services
A set of virtual DevHlp (VDH) services is used to provide an abstract but efficient means for virtual device drivers to interact with DOS sessions and the OS/2 kernel. These VDH services have the following characteristics:
- They are available through dynamic linking.
- They use the 32-bit calling conventions found in the function prototype definition VDHENTRY located in the MVDM.INC and .h include files.
- A return value of 0 (zero) usually means that the call failed. When 0 is returned, calling VDHGetErrorreturns a detailed error code. If this return is 0, the last call succeeded and 0 was a meaningful return value, not an error. A nonzero return value means that the call succeeded. See VDHGetError.
- All pointer parameters are 0:32 flat pointers.
The Memory Management Virtual DevHlp services are used for:
- Mapping
*Reservation
*Allocation/reallocation/free
See C Language Virtual DevHlp Servicesfor a list of the page-granular memory management services and a description of each virtual DevHlp.
Inter-Device-Driver Communication
A virtual device driver can communicate with a physical device driver by using the Inter-device-Driver Communication (IDC) mechanism provided by the OS/2 operating system. A virtual device driver communicates with a physical device driver directly though a callable 16:16 interface, or by using the virtual DevHlp services that map to file system APIs. Virtual device drivers communicate directly with other virtual device drivers by using a set of the virtual DevHlp services.
The type and form of communication is defined by the physical or virtual device driver that provides the IDC entry point to be called. These device drivers must be aware of addressability and be sensitive to interrupt-time performance. For example, a virtual device driver that is not reflecting hardware interrupts to applications, and is in communication with a physical device driver, should use the virtual DevHlp services that map to File System APIs to communicate. However, if the virtual device driver must reflect hardware interrupts, the physical device driver should use the 16: 32 callable interface because it provides a more sensitive interface in which to communicate.
Virtual Device Driver and Physical Device Driver Interaction
Many virtual device drivers virtualize hardware that generates interrupts. Generally, these drivers must interact with a physical device driver to fully virtualize a device. Virtual DevHlp services are provided for the Open, Close, Read, Write, and IOCtl functions of the File System, which is then routed to the corresponding physical device driver. This is the simplest IDC mechanism for VDD/PDD communication.
Where interrupt-time or other high-performance PDD/VDD IDC requirements exist, the VDHOpenPDDservice is used to establish communication between a virtual device driver and a physical device driver by exchanging entry points, which use a 32-bit calling convention (refer to the multiple DOS session-specific equates found in the MVDM.INC include files). At this point, the virtual device driver and physical device driver are free to communicate through whatever private protocol is chosen, including exchanging register-based entry points. However, both drivers must agree on a shutdown protocol, that is, what is used to stop the communication if the virtual device driver must shut down. See VDHOpenPDDfor more information.
Virtual Device Driver/Virtual Device Driver Communication
Because dynamic linking is supported between virtual device drivers, multiple virtual device drivers can support inter-virtual device driver communication through dynamic links. Where these device drivers are supplied by multiple parties and it is not required that all of the virtual device drivers in the set be present, dynamic linking does not work. The virtual DevHlp services, VDHRegisterVDD, VDHOpenVDD, VDHRequestVDD, and VDHCloseVDDare used to overcome this limitation of dynamic linking. For details, see VDHRegisterVDD, VDHOpenVDD, VDHRequestVDD, and VDHCloseVDD.
Hardware Emulation and Interrupt Support
The major functions of software interrupt emulation are:
- Hook interrupt service: see VDHInstallIntHook
*Return to DOS session interrupt handler service: see VDHPushInt
*Hook return service: see VDHArmReturnHook
Hook Interrupt Service (VDHInstallIntHook)
The handler supplied to this service is a post-reflection handler. Post- reflection handlers are called after the INT instruction is reflected into the DOS session interrupt code. A DOS session breakpoint address is put into the interrupt vector table entry at INIT time, so control returns to the kernel at the end of the DOS session's interrupt code chain. The virtual device driver interrupt handler chain is then called. The ROM routine address (or whatever was initially in the interrupt vector table), which was replaced by the DOS session breakpoint, is returned to, if the virtual device driver handlers do not call VDHPopInt. See VDHPopInt.
Return to DOS Session Interrupt Handler Service (VDHPushInt)
VDHPushIntcalls the interrupt reflection code to change the DOS session's execution flow to the DOS session's interrupt code. This is done by building a return IRET frame on the client's stack with the CS:IP and flags from the kernel stack frame. The DOS session's CS:IP on the kernel stack is edited with the address from the DOS session's interrupt vector table. See the figure in the next section.
Hook Return Service (VDHArmReturnHook)
The VDHArmReturnHookservice allows the IRET to be hooked after the VDHPushIntservice is called. A DOS session breakpoint is allocated, and the address replaces the client's CS:IP on the return IRET frame. The client's CS:IP is saved. For additional information, see VDHArmContextHookand VDHPushInt. These services are shown in the following figure.
When building the return IRET frame, the client's stack pointer can wrap around from 0 to 0FFFEH. This does not terminate the DOS session. If the client's stack pointer is equal to 1 when this function is begun (before the virtual device driver handlers are called), the DOS session is terminated (to emulate the 386 hardware when it is in real mode).
When the virtual device driver installs an interrupt handler, a DOS session breakpoint is installed in the interrupt vector table before any DOS session code hooks. The DOS session breakpoint is executed after the DOS session interrupt code chain is executed but before ROM. The virtual device driver interrupt handlers are executed until one returns the stop chainingindication, or the end-of-list is reached. ROM code is executed after the last virtual device driver handler is called unless one of these handlers calls VDHPopInt. See VDHPopInt. This service emulates the IRET when a V86 code interrupt handler has popped off the IRET frame and restored the DOS session's CS, IP, and flags to the IRET frame contents. VDHPushIntis used by the software interrupt instruction trap and by the virtual PIC device driver in the last stages of simulating hardware interrupts.
Kernel Stack Client Stack Kernel Stack Client Stack /------------\ /--------------\ /------------\ | 0 | SS | | | SS | | Flags | |------------| |--------------| |------------| | ESP | | ESP | | CS | |------------| |--------------| |------------| | EFlags | | EFlags | | IP | |------------| |--------------| \------------/ | 0 | CS | | |INT CS | |------------| |--------------| | IP | | INT IP | \------------/ \--------------/ Before VDHPushInt After VDHPushInt Kernel Stack Client Stack /--------------\ /------------\ | 0 | SS | | Flags | |--------------| |------------| | ESP | | VDMBP CS | |--------------| |------------| | EFlags | | VDMBP IP | |--------------| \------------/ | 0 |INT CS | |--------------| | INT IP | \--------------/ After VDHArmReturnHook
Access to Ports Not Trapped by a Virtual Device Driver
In order to support DOS applications that use hardware that does not have virtual device drivers, a mechanism is provided for DOS applications to access ports on those devices. This is done by having the default handler for each I/O port turn trapping OFF for the port in question. All accesses after the first one go straight through to the hardware. This is done only for ports that are not trapped by a virtual device driver.
Global and Local Context Hooks
Global context hooksare a mechanism to delay work until the CPU is at task time (as opposed to interrupt time). If a global context hook is set at task time, the handler is called immediately. Local context hooksare a mechanism to delay work until the CPU is at task time in the context of a specific process. When a virtual device driver sets a local context hook, that hook is guaranteed to execute before any user code (that is, code executing in V86 mode).
Interrupts Supported by Multiple DOS Sessions
The following interrupts are supported by multiple DOS sessions:
- BIOS hardware interrupt support
*BIOS software interrupt support
*DOS software interrupt support
*Other software interrupt support
BIOS Hardware Interrupt Support
In previous versions of the OS/2 operating system, DOS applications were prevented from hooking hardware interrupts when the IRQ level was owned by an OS/2 device driver. A DOS application that violated this rule was terminated. In the current version of OS/2 this restriction is significantly relaxed. Depending on the support provided by the device's virtual device driver, DOS applications can now hook the hardware interrupt vector. The following list summarizes the support provided by OS/2 virtual device drivers for each of the hardware interrupt request (IRQ) levels:
IRQ 0 Timer (INT 08h). The INT 08h handler is invoked on hardware interrupts from Channel 0 of the system timer. DOS applications can hook this interrupt. See the description of INT 08h in BIOS Software Interrupt Support.
IRQ 1 Keyboard (INT 09h). The INT 09h handler is invoked upon the make or break of every keystroke. DOS applications can hook this interrupt.
IRQ 2 The Cascade (Slave) Interrupt Controller. This controller supports interrupt request levels 8 through 15, as described below.
IRQ 3 Serial Ports (COM2, 3, 4). These ports are supported when the virtual and physical COM device drivers are installed.
IRQ 4 Serial Port (COM1). This port is supported when the virtual and physical COM device drivers are installed.
IRQ 5 Parallel Port 2. This hardware interrupt is simulated in DOS sessions .
IRQ 6 Diskette. This hardware interrupt is not simulated in DOS sessions. See the description of INT 0Eh in BIOS Software Interrupt Support.
IRQ 7 Parallel Port 1. This hardware interrupt is simulated in DOS sessions .
IRQ 8 Real-Time Clock. This hardware interrupt is not simulated in DOS sessions. See the description of INT 70h in BIOS Software Interrupt Support .
IRQ 9 Redirect Cascade. A virtual device driver to simulate this hardware interrupt is not provided.
IRQ 10 Reserved. A virtual device driver to simulate this hardware interrupt is not provided. See Reserved IRQ Support in OS/2for more information.
IRQ 11 Reserved. A virtual device driver to simulate this hardware interrupt is not provided. See Reserved IRQ Support in OS/2for further information.
IRQ 12 Auxiliary Device. A virtual device driver to simulate this hardware interrupt is not provided. See Reserved IRQ Support in OS/2for further information.
IRQ 13 Mathematics Coprocessor (NPX). NPX exception interrupts on IRQ 13 are reflected into the DOS session.
IRQ 14 Fixed Disk. This hardware interrupt is not simulated in DOS sessions .
IRQ 15 Reserved. A virtual device driver to simulate this hardware interrupt is not provided. See Reserved IRQ Support in OS/2below for more information.
Reserved IRQ Support in OS/2
The OS/2 operating system does not provide support for optional devices on the Reservedand Redirect Cascadeinterrupt levels in OS/2-mode sessions, or in DOS sessions. Hooking one of these hardware interrupt request levels in a DOS application has no effect. If there is no physical device driver/ virtual device driver pair to service an interrupt, the DOS application's interrupt handler is not invoked, even though the hardware interrupts are generated.
These hardware interrupt request levels can be supported in a DOS session by a user-installed virtual device driver. However, a user-installed physical device driver is also required to provide this support since there is no mechanism for a virtual device driver to directly service a hardware interrupt.
BIOS Software Interrupt Support
BIOS software interrupt compatibility considerations and restrictions for OS/2 DOS sessions are shown below. Notice that only specific compatibility considerations and functional restrictions for users of BIOS in the DOS session environment of the OS/2 operating system are listed.
02h Nonmaskable Interrupt (NMI). Not reflected to the DOS sessions; this BIOS interrupt handler is not invoked on NMI.
05h Print Screen. The BIOS INT 05h handler is supported. If the DOS application issues INT 05h, the contents of the video buffer is printed. The Shift+PrtScrkeystroke combination (or equivalent) also invokes this function.
08h System Timer. This interrupt is invoked every time the system timer Channel 0 counts down to zero (normally, 18.2 times per second). DOS applications can hook this interrupt. However, in a DOS session these timer interrupts can come in a burst and have variable latency. The INT 08h interrupt handler is emulated by the virtual timer device driver.
0Eh Diskette. The INT 0Eh handler is not used to service interrupts generated by the diskette device (IRQ 6). DOS applications should not hook this interrupt.
10h Video. The INT 10h functions are fully supported in DOS sessions. The following INT 10h functions are emulated by the virtual video device driver .
0Eh Write Teletype (TTY)
13h Write String
Note:These functions are emulated only if the INT 10h vector is unmodified. If any piece of DOS session code hooks INT 10h, emulation occurs only if these functions are passed to the virtual video device driver's interrupt hook.
13h Hard Disk/Diskette. INT 13h emulation in a DOS session supports both removable and nonremovable media. The following subset of INT 13h functions are supported in DOS sessions:
00h Reset Diskette
01h Read Status
02h Read Sectors
03h Write Sectors (Diskette only)
04h Verify Sectors
05h Format Track (Diskette only)
08h Get Drive Parameters
0Ah Read Long (Fixed Disk only)
15h Read DASD Type
16h Change Status (Diskette only)
17h Set Disk Type (Diskette only)
18h Set Media Type (Diskette only)
14h ASYNC. When the virtual COM device driver is installed, all BIOS INT 14h functions are supported. These functions are emulated by the virtual COM device driver to enhance performance:
00h Initialize Port
01h Send Character
02h Receive Character
03h Read Status
04h Extended Initialize
05h Extended Port Control
15h System Services. These services are listed in the following table:
/--------------------------------------------------------------\ |AH|Function |Description | |--+------------------------+----------------------------------| |00|Cassette Motor ON |Default. Routed to ROM BIOS. | |--+------------------------+----------------------------------| |01|Cassette Motor OFF |Default. Routed to ROM BIOS. | |--+------------------------+----------------------------------| |02|Cassette Read |Default. Routed to ROM BIOS. | |--+------------------------+----------------------------------| |03|Cassette Write |Default. Routed to ROM BIOS. | |--+------------------------+----------------------------------| |0F|Format Periodic INT |Error. On return, CF is set. | |--+------------------------+----------------------------------| |4F|Keyboard Intercept |Default. Routed to ROM BIOS. | |--+------------------------+----------------------------------| |80|Open Device |Default. Routed to ROM BIOS. | |--+------------------------+----------------------------------| |81|Close Device |Default. Routed to ROM BIOS. | |--+------------------------+----------------------------------| |82|Program Terminate |Default. Routed to ROM BIOS. | |--+------------------------+----------------------------------| |83|Event Wait |Support. Supported by VTIMER . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | 84 | Joystick Support | Default . Routed to ROM BIOS . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | 85 | SysReq Key Pressed | Support . Issued by VKBD . On | | | | return , AL = 0 ( key make ) , or AL = 1 | | | | ( key break ) . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | 86 | Wait | Support . Supported by VTIMER . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | 87 | Move Block | Error . Managed by VXMS . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | 88 | Get Extended Memory Size | Error . Managed by VXMS . On return , | | | | AX = 0 ( no Extended Memory ) . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | 89 | Switch to Protect Mode | Error . On return , AX ! = 0 ( fail | | | | switch ) . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | 90 | Device Wait | Default . Routed to ROM BIOS . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | 91 | Device Post | Default . Routed to ROM BIOS . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | C0 | Get System Config Parms | Default . Routed to ROM BIOS . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | C1 | Get EBIOS Data Area | Default . Routed to ROM BIOS . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | C2 | PS / 2 Mouse Functions | Error . On return , CF is set , and | | | | AH = 01 is an invalid function . | | | | Notice that all mouse support is | | | | through INT 33h . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | C3 | Watchdog Timeout | Ignore . On return , CF is clear . | | -- + ---------- ---------- ---- + ---------- ---------- ---------- ---- | | C4 | Prog Option Select | Default . Routed to ROM BIOS . | \ -- - ---------- ---------- ---- - ---------- ---------- ---------- ---- /
16h Keyboard. The keyboard is supported directly by the ROM BIOS INT 16h routines.
17h Printer. The printer is supported (emulated) by the virtual parallel port device driver.
19h Restart. Restart (reboot) is supported. However, this does not operate in the same manner as DOS (the system is not restarted). If the DOS setting DOS_STARTUP_DRIVE is set, the diskette or image restarts. Otherwise, the DOS session is terminated.
1Ah Time-of-Day. The virtual CMOS device driver component supports read- only access to the Real-Time Clock device. Because of this restriction, the following BIOS INT 1Ah functions are not supported in a DOS session:
01h Set RTC Count
03h Set RTC Time
05h Set RTC Date
06h Set RTC Alarm
07h Reset RTC Alarm
08h Set RTC Activated Power-on mode
0Bh Set System Timer Day Counter
80h Setup Sound Multiplexer
A DOS application can read the Real-Time Clock Count, Time, and Date. The INT 1Ah functions are not emulated by the virtual CMOS device driver. Instead, the BIOS ROM functions are executed directly. The CMOS/RTC hardware is virtualized by the virtual CMOS device driver.
1Eh Diskette Parameters. The segment address of the diskette parameters table is stored in the INT 1Eh entry.
70h Real-Time Clock Interrupt. Interrupts from the Real-Time Clock (IRQ 8) are not reflected into DOS sessions. This software interrupt handler is not used for either alarm or periodic interrupts.
DOS Software Interrupt Support
The DOS emulation component supports the documented aspects of the following DOS features:
20h Program Terminate.
21h DOS Function Request. All documented and undocumented INT 21h functions are supported by DOS emulation. However the following functions are supported, with restrictions:
4410h
4411h
4B05h
5Dh
5Eh
5Fh
64h
69h
6Dh
6Eh
Note:Function 53h is not supported by DOS emulation.
22h Terminate Address.
23h Ctrl+Break Exit Address.
24h Critical Error Handler.
25h Absolute Disk Read.
26h Absolute Disk Write. A hard error is reported on requests for nonremovable media.
27h Terminate-and-Stay-Resident.
28h Idle Loop.
2Fh Multiplex. Time slice yield (AX = 1680h) is supported. When a DOS application issues INT 2Fh with AX = 1680h, it offers to yield its time slice. This can be used by DOS applications in busy wait loops (preserves all registers).
Other Software Interrupt Support
The following are other software interrupts supported in an OS/2 DOS session:
INT 33h - Mouse
Supported. When the OS/2 virtual mouse driver is installed, the full range of INT 33h functions, as defined in the Microsoft Mouse Programmer's Reference Guideare available.
INT 4Bh - Virtual DMA Services (VDS) - Function 81h
Supported. When the OS/2 virtual DMA device driver is installed, the VDS INT 4Bh functions as defined in the Microsoft Virtual DMA Services Specification, Version 1.0are available.
INT 67h - LIM Expanded Memory Manager (EMM)
Supported. When the OS/2 virtual expanded memory manager device driver is installed, the LIM EMM V4.0 INT 67h functions as defined in the Lotus/Intel /Microsoft Expanded Memory Specification, Version 4.0are available.
Base Virtual Device Drivers
The following list contains all the base virtual device drivers included with OS/2:
- Virtual BIOS device driver (VBIOS)
*Virtual CMOS device driver (VCMOS)
*Virtual direct memory access device driver (VDMA)
*Virtual diskette device driver (VFLPY)
*Virtual hard disk device driver (VDSK)
*Virtual keyboard device driver (VKBD)
*Virtual numeric coprocessor device driver (VNPX)
*Virtual parallel port device driver (VLPT)
*Virtual programmable interrupt controller device driver (VPIC)
*Virtual timer device driver (VTIMER)
Virtual BIOS Device Driver
The virtual BIOS device driver (VBIOS) contains the mechanism to initialize the Interrupt Vector table, BIOS data area, extended BIOS data area (on a PS/2* personal computer adapter ROM area), and the system ROM. It also provides virtual access to Programmable Option Select (POS) registers (on a PS/2 personal computer) and supports some of the DOS settings.
DOS Session Creation
When a DOS session is created, the virtual BIOS device driver is responsible for allocating and initializing the following areas in the DOS session's address space with the respective values from physical memory:
- Interrupt Vector Table
*BIOS data area
*DOS communications area
*Extended BIOS data area (on a PS/2 personal computer).
The virtual BIOS device driver is also responsible for mapping the system ROM and adapter ROM into the address space of the DOS session. The per-DOS session copy of the POS registers is initialized at this time.
DOS Settings
The virtual BIOS device driver is responsible for Include/Exclude region support. The DOS setting MEM_INCLUDE_REGIONS gives the user an option to give more space to EMM/XMS. If the user knows that in a particular DOS session an adapter will not be used, then the linear region taken by that adapter can be given to EMM and XMS through MEM_INCLUDE_REGIONS. MEM_ EXCLUDE_REGIONS gives the user an option to restrict EMM and XMS from claiming a particular region. Both these options are provided through DOS settings. These DOS settings are only applicable at DOS session creation time.
Adapter ROM
At system initialization, the virtual BIOS device driver searches the region between the top of the DOS user space (RMSIZE) and 1MB to find all of the adapter ROM. Adapter ROMs that include the ROM signature will be found. In a normal DOS session creation (without any Include/Exclude properties specified), these linear addresses are mapped to corresponding physical ROM.
All the ranges specified in the DOS setting MEM_INCLUDE_REGIONS are taken out of the list used for mapping the linear addresses to corresponding physical ROM. As a result, MEM_INCLUDE_REGIONS is not mapped to physical ROM and it remains available to EMM or XMS.
For MEM_EXCLUDE_REGIONS, the virtual BIOS device driver reserves those regions and maps them to their corresponding physical addresses. This allows the user the ability to map adapter ROM that does not contain the ROM signature and adapter RAM.
Virtual CMOS Device Drivers
The virtual CMOS device driver consists of virtual support for the CMOS battery backed-up RAM, the Real-Time Clock (RTC) and the Nonmaskable Interrupt (NMI) disable logic. It provides virtual access to the address and data latches through virtual I/O ports. This component allows the majority of existing DOS applications that access its ports by direct access, or by normal BIOS calls, to operate without change.
Supported Functions
The following functions are supported by the virtual CMOS device driver:
- CMOS memory access
*I/O port support
*NMI-disable
*Read time-of-day and date
*Real-Time Clock and interrupt access
CMOS Memory Access
CMOS Memory Access provides support for passive reads and writes to virtual CMOS memory. The CMOS portion of the CMOS/RTC can be read or written. The virtual CMOS memory is initialized to the contents of the physical CMOS memory (at the time of DOS session initialization) through the physical clock device driver, which is the physical device driver of the virtual CMOS component. Values are written to the virtual CMOS memory in a buffer local to the DOS session. Unlike the physical CMOS memory, however, the contents of the virtual CMOS memory are lost when the DOS session is terminated.
Input/Output Port Support
The virtual CMOS device driver component monitors all accesses to its two DOS session I/O ports. The two ports are a write-only address latch and a read/write data latch. The address latch port has two functions, NMI Disable and CMOS/RTC Device Address Selection. The data latch is a register for holding a byte being transferred to or from the CMOS/RTC device.
Disabling Nonmaskable Interrupts
The Nonmaskable Interrupt (NMI)-Disable portion of the the address latch can be set or reset by a DOS application. However, changes to enable or disable NMI are otherwise ignored.
Read Time-of-Day and Date
This function presents the correct seconds, minutes, and hours to an application reading the appropriate locations. This function also provides atomic access to all values to avoid reading the values during time transition.
Real-Time Clock and Interrupt Access
The Real-Time Clock consists of a time-of-day clock, an alarm interrupt, and a periodic interrupt. Accesses to the Real-Time Clock to change the time of day or the timing mode, or to set an alarm or periodic interrupt, are disallowed. The CMOS/RTC registers related to the Real-Time Clock are supported for read-only access. Because interrupts can only be supported through write access to the ports, Real-Time Clock interrupts are not supported.
BIOS Support
The virtual CMOS device driver component does not emulate BIOS functions. Instead, it allows the existing BIOS functions to be used without change.
Unsupported Functions
From the perspective of the DOS session, the virtual CMOS device driver component supports access to I/O address space only. Therefore, the following functions are not supported:
- Set Time-of-Day and Date
*Set Time-of-Day Alarm
*Set/Enable Periodic Interrupt
*Enable Update Interrupt
Virtual Direct Memory Access Device Driver
The virtual direct memory access device driver (VDMA) provides per-DOS session per-direct memory access (DMA) channel virtualization. In addition, the virtual DMA device driver provides the following:
- Serializes the DOS session's DMA requests on a per-DMA channel basis (but allows simultaneous requests on different DMA channels)
- Converts the DOS session's linear addresses to physical addresses, and handles all the data movement required
- Handles all the restrictions of a DMA chip
- Supports the enhanced DMA operations and commands of a personal computer
- Optimizes DMA virtualization on personal computers by using the enhanced mode
- Supports INT 4Bh - Function 81h virtual DMA services
- Supports virtualized DMA in auto-initialization mode
In addition to the above features, the virtual DMA device driver also synchronizes the operations with other virtual device drivers registered on different DMA channels. A virtual device driver for a piece of hardware, which uses a DMA channel, registers with the virtual DMA device driver. The virtual device driver informs these virtual device drivers before starting and stopping the DMA operation on their channels.
Virtual Diskette Device Driver
The virtual diskette device driver (VFLPY) intercepts applications that try to access the diskette drive directly or issue INT 13h calls. This virtual device driver also serializes and coordinates I/O operations between multiple DOS sessions.
Obtaining Physical Diskette Hardware Ownership
When the system first starts up, the physical diskette device driver owns the physical diskette hardware. All diskette accesses from the OS/2 applications go through the file system or the physical diskette device driver, and are eventually serialized into requests. Initially, the virtual hard disk device driver does not own the diskette controller, and it hooks all the diskette ports. It requests ownership from the physical diskette device driver when the DOS session accesses any diskette port, or when the virtual DMA device driver informs the virtual hard disk device driver that the diskette DMA channel has been unmasked. If the immediate ownership request is not successful, the DOS session is blocked until the physical diskette device driver calls back and grants the ownership.
Releasing Physical Diskette Hardware Ownership
Once the virtual diskette device driver has obtained the diskette ownership , it does not release ownership until the physical diskette device driver requests it, or the diskette motor is turned OFF.
Physical Diskette Interrupt Routing
Physical diskette interrupts are always routed to the physical device driver by the interrupt manager. If the virtual diskette device driver has the exclusive hardware ownership when the interrupt happens, the physical diskette device driver routes the event to the virtual diskette device driver, which simulates the interrupt to the DOS session.
Virtual Hard Disk Device Driver
The virtual hard disk device driver (VDSK) provides virtual disk support for multiple DOS sessions and supports access to the disk through BIOS (INT 13h) calls. Since BIOS accesses the hardware ports directly, the virtual hard disk device driver component overrides the BIOS by directly emulating INT 13h for hard disks. The virtual hard disk device driver component does not provide I/O port level access to the disk controllers. Access to hardware ports that are supported for the diskette drive, and BIOS INT 13h calls, are not emulated; instead, they are run from the actual BIOS. INT 13h support includes:
AH=00h Reset diskette system
AH=01h Status of disk system
AH=02h Read sectors into memory (both diskette and hard disk)
AH=03h Write sectors from memory (diskette only)
AH=04h Verify sectors (both diskette and hard disk)
AH=05h Format track (diskette only)
AH=08h Get current drive parameters (both diskette and hard disk)
AH=0Ch Seek
AH=15h Get disk type (both diskette and hard disk)
AH=16h Change of disk status (diskette only)
AH=17h Set disk type (diskette only)
AH=18h Set media type for format (diskette only)
The INT 13h emulator is also responsible for maintaining the diskette and hard disk areas of the ROM BIOS data area.
Typical steps of an INT 13h access are listed below:
- A DOS application accesses the disk through the INT 13h interface. The INT 13h call is trapped by the virtual hard disk device driver.
- A request packet is built and sent to the physical hard disk device driver . The DOS session is then blocked, waiting for the request to finish.
- Upon receiving the request packet, if the disk is currently busy, the physical hard disk device driver queues the request.
- When the request is completed, the physical device driver notifies virtual device driver, which unblocks the DOS session.
Because the virtual hard disk device driver component does not support register level accesses of the disk controller, all accesses to its registers are trapped and ignored.
Note:Timing-related copy protection can fail because real-time access is not guaranteed. Sector WRITE and FORMAT requests are not supported for hard disk. Sector WRITE and FORMAT operations are supported for diskette.
Virtual Numeric Coprocessor Device Driver
The virtual numeric coprocessor device driver (VNPX) provides virtual coprocessor (80 x 87) support for multiple DOS sessions. The virtual numeric coprocessor device driver coordinates exception and interrupt reflection for the real coprocessor. Machines with the 80386 B1 processor, or without a coprocessor, do not have coprocessor support.
Virtual Keyboard Device Driver
The virtual keyboard device driver (VKBD) consists of virtual support for the keyboard. It allows keystrokes to be passed from the keyboard to the DOS session and text to be pasted from another application into the DOS session as keystrokes. This virtual device driver also allows existing DOS applications that access the keyboard to operate without change. Such applications can access the keyboard through BIOS calls, access to the BIOS data area, or monitoring of the keyboard interrupt, and reading keystroke data directly from the I/O ports.
The virtual keyboard device driver addresses the following issues:
- INT 21h Access. DOS applications can access the keyboard by opening the " CON:" (console) device, or by default standard input access.
- BIOS Access. DOS applications can access the keyboard through BIOS INT 09h and INT 16h.
- I/O Port Access. DOS applications can access the keyboard by reading and writing I/O ports 60h and 64h. This access is not restricted to reading scan codes, and can include other types of access (such as LED control).
- Pasting. Data can be pasted from other OS/2 applications.
- Internationalization. Keystrokes are translated according to the current keyboard translation table and code page.
- Idle Detection. DOS applications must not waste excessive CPU time when in input peek loops.
Levels of I/O Support
The various levels of support for the virtual keyboard device driver are as follows:
- BIOS support
*CON device driver support
*DOS support
*Idle detection support
*I/O port support
*Pasting support
BIOS Support
Since the BIOS INT 16h service only references the BIOS data area for keystrokes, the BIOS continues to provide this service.
The BIOS INT 09h interrupt service routine, however, is emulated within the virtual keyboard device driver. When the INT 09h vector is invoked, the virtual keyboard device driver passes the character to the physical device driver, which translates the character according to the current translation table.
It is possible for an application or a DOS memory-resident program to hook the INT 09h vector. Often, such applications simply monitor keystrokes, and pass them on to the previously-hooked interrupt service routine. In this case, the virtual keyboard device driver emulation code still runs and translates scan codes according to the current translation table. Otherwise , if an application that has hooked INT 09h fails to pass the scan code on, then the scan code is not translated, or placed into the BIOS data area by the virtual keyboard device driver.
CON Device Driver Support
This support consists of allowing the virtual console device driver to be replaced. Although the default virtual console device driver. restricts keyboard access to BIOS calls, user-supplied drivers can access the keyboard through I/O ports or through the BIOS data area.
DOS Support
This support consists of keyboard access through the various INT 21h functions. In particular, this is support for access from the DOS emulation component. For compatibility, DOS calls the virtual console device driver to read keystrokes. This allows the virtual console device driver to be replaced without ill effect.
Idle Detection Support
DOS applications waste CPU time in a multitasking system when they peek for input in a loop. Idle conditions are detected when:
- The application is polling the keyboard using INT 16h in a loop
*DOS is polling in an input loop
*Repeated INT 28h calls are received from a DOS application
*INT 2Fh, AX=1680h yield calls are received
*DOS INT 21h, service 0Bh calls are received
Two services are available to device drivers to assist and for handling, VDHReportPeekand VDHWakeIdle.
I/O Port Support
The virtual keyboard device driver is responsible for supporting programs that access the keyboard ports directly. These ports provide access to data ports on the hardware that controls I/O to the keyboard. This support is provided primarily for applications that simply read the scan code directly from the port. However, other functions are possible, such as setting the key repeat rate. Repeat rates affect the entire system; per-DOS session repeat rates are not supported. Extended scanner functions, such as providing keyboard pre-controller translation, are not supported; such commands are ignored.
Pasting Support
The virtual keyboard device driver supports two levels of pasting from the clipboard into a DOS session; fast pastingand slow pasting. In fast pasting support, characters from the clipboard are put directly into the BIOS buffer. For those DOS applications that get their key strokes from the BIOS key buffer (through INT 16h), fast pasting is adequate. For those DOS applications that hook INT 09h or INT 15h (AH=4Fh), key scan sequences are expected, which must be generated by the slow pasting mechanism.
In slow pasting, every character from the clipboard is reverse translated into scan sequence and can involve generating make-and-break scans of not only the character itself, but also the make and break of the shift keys in order to adjust the upper, lower, or control case of the character. It can even involve generating Alt+numeric keypadscan sequences for those characters, which cannot be directly typed on the keyboard (such as graphics characters or international characters).
Virtual Programmable Interrupt Controller Device Driver
The virtual PIC device driver (VPIC) is responsible for the virtualization of the 8259 Programmable Interrupt Controller (PIC) for multiple DOS sessions and for the simulation of interrupts to DOS sessions. Performance is a major requirement for hardware interrupt simulation. In this book, hardware interruptand interrupthave the same meaning. Simulated interrupt , interrupt simulation, and hardware interrupt simulationall refer to the virtual PIC device driver sending an interrupt to a DOS session.
The virtual PIC device driver supports the hardware interrupt-related services needed by virtual device drivers and DOS sessions. The services include setting handlers to trap EOI and IRET events, simulating interrupts to DOS sessions, and handling PIC I/O accesses by DOS sessions. See Virtual Interrupt Servicesfor a list of these virtual DevHlp services. The virtual PIC device driver maintains a per-DOS session virtual PIC state so that each DOS session appears to have its own independent 8259 Programmable Interrupt Controller. Provisions are included to demand page DOS sessions interrupt handling code. The virtual PIC device driver provides a DOS session with the following services:
- Virtualization of the 8259 PIC ports:
-Separate master and slave PICs
-Mask and unmask IRQ commands
-Specific and nonspecific EOI commands
-Read IR and IS register commands
- Hardware interrupts that can be be postponed until task time so that a DOS session can be paged
- Interrupts from an optional hardware adapter, which does not have a virtual device driver and a physical device driver, that can be simulated to a DOS application
The virtual PIC device driver provides virtual device drivers with:
- A high-performance mechanism to send hardware interrupts to DOS sessions:
-Support for more than one virtual device driver to share an interrupt level
-Support for a virtual device driver to regain control when a DOS session issues EOI commands, or when a DOS session executes the IRET at the end of the interrupt routine
- A mechanism for virtual device drivers to send a virtual EOI to the virtual PIC device driver
- A way to block until an interrupt is simulated
- A mechanism to query a DOS session's virtual IRQ state or status:
-Masked or unmasked state (IMR)
-Waiting to be sent to a DOS session state (IRR)
-Executing DOS session's interrupt handler code state (ISR)
-Pending interrupt routine IRET state
Hardware interrupt simulation is closely tied to the PIC virtualization. Virtual device drivers need a fast mechanism to call a DOS session's real- mode interrupt handler for a hardware interrupt. Because paging of DOS sessions (and therefore DOS session interrupt handlers) is required, simulated interrupts are delayed until the task-time context of the target DOS session.
Virtual Timer Device Driver
The virtual timer device driver (VTIMER) provides virtual timer support for multiple DOS sessions. This virtual timer device driver emulates the Intel* * 8254A Programmable Interval Timer.
DOS Support
The virtual timer device driver provides the following:
- Virtualization of timer ports to allow reprogramming of the interrupt rate and the speaker tone frequency
*Distribution of timer ticks to DOS sessions
*Maintenance of the timer tick count in the BIOS data area
*Serialization of Timer 0 and Timer 2 between the virtual timer device driver and the physical timer device driver
Virtual Parallel Port Device Driver
The virtual parallel port device driver (VLPT) consists of virtual support for direct hardware access to the three parallel ports (LPT1, LPT2, and LPT3), and for the printer-related BIOS entry points (Printer I/O INT 17h, Print Screen INT 05h). Existing DOS applications that access the parallel ports, either by direct access to the ports or by printer BIOS, operate without change. The VLPT provides the virtualization to allow multiple DOS applications to access virtual printer hardware simultaneously. This virtual device driver, in conjunction with the spooler, attempts to prevent multiple DOS applications that transmit data by using BIOS functions or direct hardware access, from intermixing output at the parallel port.
The virtual parallel port device driver consists of several sections:
- BIOS INT 17h Emulation
*BIOS INT 05h Emulation
*Printer Close Processing
*Direct I/O Access
BIOS INT 17h Emulation
One method DOS applications can use to send data to a printer is to use BIOS interrupt 17h. The VLPT emulates BIOS INT 17h and passes these requests through the file system to the physical parallel port device driver (PLPT) by using the system services VDHOpen, VDHWriteand VDHClose. See VDHOpen. VDHWrite, and VDHClose. These functions are not passed to the BIOS for processing.
The BIOS INT 17h emulation supports three functions:
- Print Character. The Print Character function buffers single character requests in the virtual device driver buffer associated with each device in a DOS session. When the buffer becomes full, its contents are sent to the VLPT by using VDHWrite. If the device is not open, the VLPT issues VDHOpento obtain a file handle and start a printer data stream. See VDHWriteand VDHOpen.
- Initialize. The virtual parallel port device driver buffer is sent to the physical parallel port device driver by using VDHWrite. The printer data stream is closed by using VDHClose. See VDHWriteand VDHClose.
When the spooler is enabled, closing the data stream closes the spool file. Any subsequent printing will open a new spool file. The beginning of the spool file contains escape sequences to reset the printer to its power-on defaults. When the spooler is disabled, no initialization of the device takes place.
- Read Status. The Read Status function returns the contents of the virtual device status register.
See Printer Close Processingfor the possible methods of closing a printer data stream opened with BIOS INT 17h.
BIOS INT 05h Emulation
The method used to send data from the display to the printer (LPT1) is to press the Print Screenkey. DOS applications can also initiate a Print Screen function by issuing a call to a BIOS INT 05h function. The virtual parallel port device driver passes this request to BIOS for processing. The virtual device driver performs some special processing to prevent the INT 05h request from intermixing with an INT 17h print request to the same device. Also, two BIOS INT 05h requests cannot be performed simultaneously from within the same DOS session. The second print screen request is ignored.
Printer Close Processing
BIOS printer interrupts operate on a single-character basis, which can have a negative impact on printer and system performance. For this reason, the VLPT buffers BIOS print requests. When the buffer becomes full, print requests are sent to the file system to be spooled and printed. The size of the application's print request is rarely an even multiple of the VLPT buffer size. This causes the virtual device driver to provide methods of flushing the remaining characters in its buffer.
A virtual parallel port device driver's BIOS INT 17h buffers are flushed in one of four ways:
- DOS settings PRINT_TIMEOUT automatic close feature
*Ctrl+Alt+Print Screen key sequence (VDHPrintClose)
*Application termination
*DOS session termination
DOS Settings PRINT_SEPARATE_OUTPUT
The user can set the DOS setting PRINT_SEPARATE_OUTPUT to specify whether or not the virtual parallel port device driver should separate INT 17h output sent to the same device by two different DOS programs that are running in the same DOS session.
If set OFF, the VLPT will not open a new data stream each time the Program Segment Prefix (PSP) changes.
PRINT_TIMEOUT
The user can set the DOS setting PRINT_TIMEOUT to specify the length of time in seconds that the VLPT will wait between occurrences of INT 17h before flushing its buffer. A setting of 0 (zero) specifies to wait indefinitely, that is, to never flush the buffer using the timeout mechanism. The PRINT_TIMEOUT mechanism flushes the buffer and closes the data stream automatically each time the DOS application stops printing by using INT 17h for the time specified.
Ctrl+Alt+Print Screen Key Sequence
After the DOS application has printed the entire file (issued INT 17h), the virtual parallel port device driver can be alerted to flush the remaining characters in its buffer by pressing Control+Alt+Print Screen. The virtual keyboard device driver calls VDHPrintClose(an exported virtual parallel port device driver entry point) to alert the virtual parallel port device driver that the key sequence has been pressed, and to flush the buffer. See VDHPrintClose.
Application and DOS Session Termination
The virtual parallel port device driver is notified when the application terminates or the DOS session is closed, and will flush the remaining characters in its buffer.
Direct I/O Access
The virtual parallel port device driver, at its initialization, registers an Inter-device Driver Communication (IDC) with the physical parallel port device driver. The VLPT requests exclusive access to the parallel port hardware through the VDD/PDD IDC when a DOS application interfaces directly with the hardware. Data transmitted using the direct I/O access method will bypass the spooler. Completion of exclusive access occurs when the key combination Ctrl+Alt+Print Screenis pressed, the application is terminated , or the DOS session is terminated.
Share Access is an option of the spooler that enables multiple DOS applications to simultaneously access the parallel port. The option is enabled by selecting the Share Accesscheckbox in the Parallel Port Settings dialog box found on the output page of the Print Object Setting Notebook.
Once enabled, multiple copies of DOS applications that access security devices attached to the parallel port can be started simultaneously. Use of this option turns OFF the serialization of accesses (the protection mechanism) to the parallel port.
One DOS application can overwrite another that is using the parallel port, causing the latter application to fail.
Interrupt-Driven Data Transfers
The virtual parallel port device driver reflects virtual hardware interrupts to applications executing in a DOS session.
Bidirectional Data Transfers
The extended mode of the PS/2 personal computer parallel port allows the port to be used as a bidirectional eight-bit parallel interface. This capability is supported by the virtual parallel port device driver when DOS applications directly access the parallel port hardware.
Enabling DOS Print TSRs
The DOS operating system implements its printing function by passing print requests from its INT 21h interface to the single character BIOS INT 17h interface. Many Terminate-and-Stay-Resident (TSR) DOS applications hook into the INT 17h vector chain to perform additional processing (such as font support, spooling, and character set downloading) before sending the print data to the device attached to the parallel port. They expect all print data to pass through to the INT 17h interface.
Since these additional functions are now provided by the OS/2 operating system and since BIOS INT 17h is not performance-sensitive, the operating system passes INT 21h print requests as buffers through the file system to the physical parallel port device driver for transmission instead of sending print requests as single character requests to BIOS INT 17h. The gain, by this approach, is the increased throughput and better utilization of the device attached to the parallel port. The trade-off has been the inability of some DOS TSR applications to perform their print functions.
LPTDD.SYS is a DOS device driver that can be installed to convert DOS session INT 21h print requests to INT 17h and thereby enable this class of DOS TSRs. By using the "DEVICE=" statement in the CONFIG.SYS file or the DOS_DEVICE option in DOS Settings, the device driver can perform the INT 17h conversion either in all DOS sessions, or in individual DOS sessions corresponding to the two methods, respectively.
Installable Virtual Device Drivers
The following list contains all the installable virtual device drivers included with OS/2:
- Virtual ASPI device driver (VASPI)
- Virtual CDROM device driver (VCDROM)
- Virtual COM device driver (VCOM)
- Virtual DOS protect-mode extender device driver (VDPX)
- Virtual DOS protect-mode interface device driver (VDPMI)
- Virtual WIN-OS/2 support device driver (VWIN)
- Virtual expanded memory specification device driver (VEMM)
- Virtual extended memory specification device driver (VXMS)
- Virtual keyboard device driver services
- Virtual Advanced OS/2 Joystick Device Driver
- Virtual mouse device driver (VMOUSE)
- Virtual touch device driver (VTOUCH), discussed in Chapter 5
- Virtual video device drivers (VCGA, VEGA, VMONO, VVGA, VXGA, V8514A), discussed in Chapter 5
Virtual ASPI Device Driver
The virtual ASPI device driver (VASPI) enables ASPI support for ASPI applications running in a DOS or WIN-OS/2 session of OS/2. Under DOS, users typically load an ASPI manager that routes all requests directly to the hardware. ASPI drivers, such as ASPIDISK and ASPICD, send requests to the ASPI manager, which then sends the command on to the appropriate device.
Under OS/2, applications that wish to send ASPI requests do so by routing the requests to a device manager (OS2ASPI.DMD), which converts them into requests that are recognizable to any SCSI-adapter device driver (ADD).
During initialization, VASPI establishes communication with OS2ASPI.DMD. This allows VASPI to route all DOS SCSI requests to OS2ASPI.DMD.
Virtual CDROM Device Driver
The virtual CDROM device driver (VCDROM) enables data and audio support for CDROM applications running in DOS sessions of OS/2. Under DOS, audio and other IOCtl support is provided through the pass-through function of the CDROM file system driver, MSCDEX* DOS applications build a device driver IOCtl request packet and then send it to MSCDEX to be forwarded to the CDROM device manager for service. The position of VCDROM in the CDROM subsystem is shown in the following figure.
/-------------\ /-------------\
| OS/2 CDROM | | DOS CDROM |
| Application | | Application |
\-------------/ \-------------/
� | | \-----�----\ INT 21h
/-------------\ | | /-------------\
| MMPM/2 | | | | DOS |
| Subsystem | | | | File System |
\-------------/ | INT 2fh | \-------------/
\--------�| / - - - - + - - - - - - - + - - - - \
| | � � |
| | /-------------\ /-------------\ |
| | | OS/2 Virtual| | DOS MSCD001 | |
| | |Device Driver| |Device Driver| |
| | \-------------/ \-------------/ |
| | � � |
| \ - - - - + - - - - - - - + - - - - /
| | |
File System API |�------------------------------/
� Virtual Device Helper API
/-------------\
| OS/2 CDROM |
| File System |
\-------------/
� File System Helper API
/-------------\
| OS/2 CDROM |
| Device Mgr |
\-------------/
| SCSI-2 Commands
|-------------\
| �
| /-------------\
| | SCSI-2 |
| | Emulation |
| | Filter |
| \-------------/
| | Vendor-Unique
/-----------------\ | SCSI-1 Commands
� � �
/-------------\ /-------------\
| Non-SCSI | | SCSI Bus |
| Host Adapter| | Adapter |
|Device Driver| |Device Driver|
\-------------/ \-------------/
� �
/-------------\ /-------------\
| Non-SCSI | | SCSI |
| Host Adapter| | Bus Adapter |
\-------------/ \-------------/
� �
/-------------\ /-------------\
| CDROM Drive | | CDROM Drive |
\-------------/ \-------------/
The virtual CDROM device driver provides two distinct features that are necessary to support DOS CDROM applications. First, this virtual device driver emulates MSCDEX by providing the services that CDROM applications require for installation (for example, the version of MSCDEX, the number of CDROM devices that are present in the system, and the drive letters that correspond to the CDROM devices). A listing of MSCDEX Command Codes is given in the following table:
/-------------------------------------------------------------\ |Command |Function Description | |--------------------+----------------------------------------| |00h |Get Number of CDROM Drive Letters | |--------------------+----------------------------------------| |01h |Get CDROM Drive Device List | |--------------------+----------------------------------------| |02h |Get Copyright File Name | |--------------------+----------------------------------------| |03h |Get Abstract File Name | |--------------------+----------------------------------------| |04h |Get Bibliographic File Name | |--------------------+----------------------------------------| |05h |Read VTOC | |--------------------+----------------------------------------| |06h |Reserved | |--------------------+----------------------------------------| |07h |Reserved | |--------------------+----------------------------------------| |08h |Absolute Disk Read | |--------------------+----------------------------------------| |09h |Absolute Disk Write | |--------------------+----------------------------------------| |0Ah |Reserved | |--------------------+----------------------------------------| |0Bh |CDROM Drive Check | |--------------------+----------------------------------------| |0Ch |MSCDEX Version | |--------------------+----------------------------------------| |0Dh |Get CDROM Drive Letters | |--------------------+----------------------------------------| |0Eh |Get/Set Volume Descriptor Preference | |--------------------+----------------------------------------| |0Fh |Get Directory Entry | |--------------------+----------------------------------------| |10h |Send Device Request | |--------------------+----------------------------------------| |11h - 0FFh |Reserved | \-------------------------------------------------------------/
The second, and major, function of the virtual CDROM device driver is to translate the DOS-style IOCtls into requests that the physical CDROM device driver can understand.
A comparison of DOS-style IOCtls and OS/2-style IOCtls is given in the following table:
/--------------------------------------------------------------------------\ |DOS | |OS/2 | | | |----------+----------+----------+----------+------------------------------| |Category |Function |Category |Function. |IOCtl/Command Description | |----------+----------+----------+----------+------------------------------| |02h |00h |*** (7) | |Return Address of Device | | | | | |Header | |----------+----------+----------+----------+------------------------------| |02h |01h |80h |70h |Return Location of Head | |----------+----------+----------+----------+------------------------------| |02h |04h |81h |60h |Return Audio-Channel | | | | | |Information | |----------+----------+----------+----------+------------------------------| |02h |06h |80h |60h |Return Device Status | |----------+----------+----------+----------+------------------------------| |02h |07h |80h |63h |Return Sector Size | |----------+----------+----------+----------+------------------------------| |02h |08h |80h |78h |Return Volume Size | |----------+----------+----------+----------+------------------------------| |02h |09h |*** (8) | |Return Changed Media Code | |----------+----------+----------+----------+------------------------------| |02h |0Ah |81h |61h |Return Audio-Disc Information | |----------+----------+----------+----------+------------------------------| |02h |0Bh |81h |62h |Return Audio-Track Information| |----------+----------+----------+----------+------------------------------| |02h |0Ch |81h |63h |Return Audio-Subchannel Q Info| |----------+----------+----------+----------+------------------------------| |02h |0Eh |80h |79h |Return UPC | |----------+----------+----------+----------+------------------------------| |02h |15h |81h |65h |Return Audio-Status | | | | | |Information | |----------+----------+----------+----------+------------------------------| |03h |00h |80h |44h |Eject Disc | |----------+----------+----------+----------+------------------------------| |03h |01h |80h |46h |Lock/Unlock Door | |----------+----------+----------+----------+------------------------------| |03h |02h |80h |40h |Reset Drive | |----------+----------+----------+----------+------------------------------| |03h |03h |81h |40h |Audio-Channel Control | |----------+----------+----------+----------+------------------------------| | |*** (1) |80h |61h |Identify CDROM Driver | |----------+----------+----------+----------+------------------------------| | |*** (2) |80h |72h | Read Long | | ---------- + ---------- + ---------- + ---------- + ---------- ---------- ---------- | | | * * * ( 3 ) | 80h | 50h | Seek | | ---------- + ---------- + ---------- + ---------- + ---------- ---------- ---------- | | | * * * ( 4 ) | 81h | 50h | Play Audio | | ---------- + ---------- + ---------- + ---------- + ---------- ---------- ---------- | | | * * * ( 5 ) | 81h | 51h | Stop Audio | | ---------- + ---------- + ---------- + ---------- + ---------- ---------- ---------- | | | * * * ( 6 ) | 81h | 52h | Resume Audio | \ ---------- - ---------- - ---------- - ---------- - ---------- ---------- ---------- /
Note:
1. Command is not available in DOS.
2. DOS Extended Device Driver Command 130h.
3. DOS Extended Device Driver Command 131h.
4. DOS Extended Device Driver Command 132h.
5. DOS Extended Device Driver Command 133h.
6.. DOS Extended Device Driver Command 136h.
7. Command is not available in OS/2.
8. Corresponds to OS/2 block device driver command 01h.
The virtual and physical CDROM device driver's provide roughly the same device services, but through different IOCtl interfaces. The DOS CDROM interface is available through the IOCtl input and output device driver request packets, while the physical CDROM device driver provides its services through the generic IOCtl interface. The virtual CDROM device driver maps the DOS IOCtls to their corresponding physical device driver IOCtls, and then passes them on to the physical CDROM device driver. On return from the physical CDROM device driver, the virtual CDROM device driver also maps the return information and the return codes back into the DOS-style environment.
The virtual CDROM device driver provides full emulation of MSCDEX. MSCDEX Version 2.21 is fully supported under IBM Operating System/2
Virtual COM Device Driver
The virtual COM device driver (VCOM) consists of virtual support for the serial communication I/O ports, and for the serial channel-related BIOS entry points. It provides support in each DOS session for up to four COM ports. In addition, this component allows existing DOS applications, which access communications channels by direct access to the I/O ports or by normal BIOS calls, to operate without change.
The VCOM only supports access to communication channels that are physically present on a given system. This does not include support for accessing communication devices that can be redirected by network software. From the perspective of the DOS session, the VCOM supports access through:
- BIOS
*I/O address space
Support Summary
The VCOM directly supports invocations of BIOS INT 14h, instead of allowing the BIOS to access the ports directly. However, direct access to the virtual I/O ports is also supported. Direct access to I/O ports results in emulation of a communication controller with the INS8250 UART. When referenced through the virtual I/O ports, the VCOM also provides all support for virtual interrupt indication. The hardware appears to the DOS session as a serial interface supported by standard expansion bus serial ports on a PS/2 personal computer.
Interrupt Service
The virtual COM device driver provides full support for the virtualization of communication channel interrupts, and follows the same logic as the actual hardware.
Virtual DOS Protect-Mode Extender Device Driver
The virtual DOS protect-mode extender device driver (VDPX) provides address translation from protect mode to V86 mode for DOS protect-mode interface ( DPMI) applications. This translation is necessary because DPMI applications run in protect mode but issue interrupt requests, which can be handled in V86 mode, to perform various system services. When running in protect mode, the application is using selectors instead of segments. Therefore, any data buffers in the protect-mode memory address space (above 1MB) must be copied into a region of memory within the V86 address space.
The vdpx registers the DOS setting DPMI_DOS_API, which controls whether the VDPX is active or not. If the user selects:
Enabled The VDPX always translates the interrupts it supports from protect mode to V86 mode.
Auto The application must first issue the following INT 2Fh in protect mode to begin the translation:
ENTRY AX = 168Ah
DS:(E)SI points to the ASCIIZ
string "MS-DOS"
EXIT If VDPX fails initialization:
AL = 0x8A
Note:MS-DOS is a trademark of Microsoft Corporation.
Disabled The VDPX does not perform any address translation.
DPMI applications can provide their own translation services. Therefore, it might be unnecessary for the VDPX to perform any address translation.
The VDPX translates various interrupts from protect mode to V86 mode, including INT 10h, 15h, 21h, 25h, 26h, 2Ah, 33h, and 5Ch. The VDPX translates most of the commonly-used functions for these interrupts. After the virtual device driver translates the interrupt, the V86-mode interrupt service routine (or the virtual device driver, if it has hooked the interrupt) handles the interrupt request. After issuing the interrupt in V86 mode, the VDPX ensures that any data returned from the V86 service is copied into the data area originally passed in by the DPMI application. The registers and flags returned by the V86-mode handler (other than mode- sensitive registers such as segment registers) are returned to the DPMI application.
Virtual DOS Protect-Mode Interface Device Driver
The virtual DOS protect-mode interface device driver (VDPMI) provides Version 0.9 DPMI support for applications in a DOS session. DPMI applications run in protect mode instead of V86 mode. The VDPMI provides the necessary support to allow DPMI applications to run under OS/2. The VDPMI supports the DPMI memory limit DOS setting, which allows the user to specify how much protect-mode memory should be available to the DOS session .
The VDPMI supports INT 31h in protect mode, which is issued by DPMI applications to request a DPMI service. The VDPMI device driver keeps track of the resources used by the application, such as memory, selector, interrupt, and debug watchpoint management. This virtual device driver also supports the mechanisms necessary to allow DPMI applications to switch the DOS session in and out of V86 mode (translation services). When a DPMI application terminates, the virtual DPMI device driver ensures that all of the DPMI application resources are freed.
If a DPMI application issues an interrupt in protect mode and there is no protect-mode interrupt handler, the request is reissued in V86 mode. Most virtual device drivers hook only interrupt requests in V86 mode, so they are not called until the interrupt is reflected to V86 mode unless the virtual device driver has issued VDHSetVPMIntVector. (see VDHSetVPMIntVector). However, it is up to the application or the virtual DOS protect-mode extender device driver (VDPX) to do any address translation that is necessary, such as converting the selector address to a segment address. See Virtual DOS Protect-Mode Extender Device Driverfor further information on address translation.
DPMI 1.0 Functions Supported
- 401 - Get DPMI Capabilities
- 504 - Allocate Linear Memory Block
- 509 - Map Conventional Memory in Memory Block
- E00 - Get Coprocessor Status
- E01 - Set Coprocessor Status
- Separate Local Descriptor Table (LDT) and Interrupt Descriptor Table (IDT) for each protect-mode client
Virtual WIN-OS/2 Support Device Driver
The virtual WIN-OS/2* support device driver (VWIN) provides interfaces and transport services which enable DOS and OS/2 applications to do communication between processes in a very fast, event-driven, specialized way. The clipboard, DDE and WIN-OS/2 window functions use these interfaces to exchange data between WIN-OS/2 sessions and the Presentation Manager desktop.
The data and messages which pass through VWIN are not actually inspected nor understood by the driver. Instead, the driver provides a store and forward mechanism. To accomplish this, an interface is exported for each environment. In an OS/2 session, a thread of the OS/2 process blocks in VWIN waiting for data from any of the other processes. In a DOS session and in a WIN-OS/2 session, the address of a notification routine is registered, and this routine is invoked when a message or data is available from one of the other processes using the interface. Interfaces are provided which allow for sending messages and data to other specific processes or for broadcasting to all processes. This system is outlined in the illustration below:
/------------\ /----------------\
| OS/2 | |DOS or WIN-OS/2 |
| Process | | Process |
\------------/ \----------------/
� �
| /------------\ |
| | VWIN | |
\---�| |�----/
\------------/
Virtual Expanded Memory Specification Device Driver
The Lotus/Intel/Microsoft Expanded Memory Specification, Version 4.0(LIM 4 ) provides a standard interface for the use of expanded memoryon 8086- family computers. This specification offers up to 32MB of expanded memory divided into as many as 255 expanded memory objects. Regions of these objects can be mapped at 8086 addresses (below 1MB), thus allowing DOS applications access to large memory allocations. However, the memory that is to be accessed must be explicitly mapped.
Alternate page tables are provided for quick switches among mappings and function calls with remapping. These tables are also used as the means to save and update mappings, or move and exchange memory contents.
The OS/2 virtual expanded memory specification (EMM) device driver:
- Implements all the INT 67h functions in the LIM 4.0 EMS, except those for the DMA registers.
- Provides each DOS session with a separate EMS emulation. A DOS session has its own set of expanded objects so that features such as interprocess communication work as if each DOS session was running on a different real 80386 DOS sessions cannot affect the availability of objects, or access memory in other DOS sessions.
- Provides support for remapping of conventional memory (below 640KB) for use by programs.
- Provides a configurable limit for the amount of EMS memory available per DOS session.
- Supports multiple physical to single logical mappings. Different 8086 addresses can map to the same expanded memory object address.
Configurable Defaults
Default values are set for properties in order to be appropriate in most instances. However, users can change these defaults, if desired. The following defaults can be set in the CONFIG.SYS file:
Default EMS Memory Size Default limit set by specifying the number of kilobytes of memory desired on a "DEVICE=" line in the CONFIG.SYS file. Alternately, the limit can be specified by using a switch, /S=xxx, on the line. For example:
DEVICE=path\VEMM.SYS 1024
or
DEVICE=path\VEMM.SYS/S=1024
Default EMS Low OS Map Region Size of remappable conventional memory set by using the /L switch. For example:
DEVICE=path\VEMM.SYS /L=256
EMS High OS Map Region Size of extra mappable memory (other than the 64KB minimum) set by using the /H switch. For example:
DEVICE=path\VEMM.SYS /H=32
EMS Frame Location Default frame position set by using the /F switch. Any value in the DOS setting list can be chosen as the default. For example:
DEVICE=path\VEMM.SYS /F=AUTO
or
DEVICE=path\VEMM.SYS/F=C800
When devices without virtual device drivers can directly map memory, the Include and Exclude regions are crucial for the virtual EMM device driver. These properties are supplied by another component, and determine which regions can be directly mapped to physical addresses by default when touched by applications.
The virtual DevHlp Mapping services allow the same master page to be aliased in by successive pages in the V86 address space. In particular, EMM allows an application to map in the same 16KB size range of memory repeatedly (for example, a 64KB page frame could consist of the same four pages mapped four times). Since DMA requires contiguous physical memory, I/ O that involves aliased pages, which map to the same physical page, must be handled by breaking up DMA requests.
Virtual Extended Memory Specification Device Driver
The Extended Memory Specification, Version 2provides a standard interface for the use of extended memoryon 80286- and 80386-based machines. The XMS specifications manage three distinct regions of memory:
- High Memory Area (HMA). Extended memory accessible from real mode by enabling the A20 address line. Code can be executed in the HMA, if the A20 line is enabled. The high memory area is exactly 65520 bytes (64KB-16 bytes ) long.
- Extended Memory Blocks (EMBs). Blocks of extended memory accessible by way of XMM function calls through a handle. Without leaving V86 mode, code cannot be executed from EMBs; they serve only for data storage. The specification offers up to 64MB of extended memory divided into as many as 255 blocks.
- Upper Memory Blocks (UMBs). Block of memory located between 640KB and 1MB. Once a UMB is allocated, its memory is always available. Since the memory lies in conventional memory, code can be executed in it at any time.
The virtual extended memory specification (XMS) device driver:
- Implements all the functions in XMS 2.0.
- Provides each DOS session with a separate XMS emulation. Each DOS session has its own high memory area, upper memory blocks, and extended memory blocks so that features such as interprocess communication perform as if each DOS session was running on a different real 80386. A DOS session cannot affect the availability of objects, or access memory in another DOS session.
- Provides configurable limits for the amount of XMM memory available across DOS sessions, and a limit per DOS session. An installed program in the start list should be able to override the per-DOS session limit, subject to the constraint given by the overall limit. In addition, it should be able to disable XMS completely for a particular DOS session, if its installation would conflict with the program running in the DOS session.
A CONFIG.SYS line of the form DEVICE=path\VXMS.SYS [options], will interpret optionsas "/keyword=value". These options are as follows:
/XMMLIMIT=g,i Set the global (system-wide) maximum memory usage of the virtual XMS device driver to gKB, and set a per-DOS session maximum of iKB. These values are large enough to accommodate an automatic 64KB allocation in each DOS session for the HMA. Values are restricted to the range 0 through 65535 (=64KB).
The values of gand iare rounded up to the nearest multiple of four. Specifying i=0 suppresses XMS installation in all DOS sessions unless overridden by a DOS session-specific configuration string. The default for /XMMLIMIT is 16384,2048.
/HMAMIN=d Set the minimum request size (in kilobytes) for an HMA request to succeed. Values are restricted to the range 0 through 63. The default for / HMAMIN is 0.
/NUMHANDLES=n Set the number of handles available in each DOS session. Each handle occupies eight bytes. Values are restricted to the range 0 through 128. The default for /NUMHANDLES is 32.
/UMB Instruct XMM to create Upper Memory Blocks (UMB). The default is / NOUMB.
/NOUMB Instruct XMM to not create Upper Memory Blocks (UMB). The default is /NOUMB.
Virtual Keyboard Device Driver Services
The virtual video device driver utilizes the Post Peek and Post Read requests from the virtual keyboard device driver to post events to the DOS session Window Manager when the windowed DOS session video state changes. In addition to generating the VVDEVENT_INPUT event to the DOS session Window Manager to adjust window orientation, these notifications also serve to suggest to the virtual video device driver when to check for palette and LVB changes, which generate VVDEVENT_PALETTE and VVDEVENT_LVB events.
The virtual keyboard device driver uses the Post Paste request to indicate whether paste operations can start or end. The virtual video device driver posts the VVDEVENT_PASTE or VVDEVENT_ENDPASTE event to the DOS session Window Manager, based on the type of paste operation requested.
Virtual Advanced OS/2 Joystick Device Driver
The virtual joystick device driver has two main purposes:
- To provide a reliable joystick device driver for DOS games running under OS/2.
- To provide a standard device driver for OS/2 game programmers that they can use as an interface between the PC game adapter port and their products .
See the OS/2 Input/Output Device Driver Referencefor detailed information on understanding how the IBM PC Game-Port Adapter works and using the Advanced OS/2 Joystick Device Driver.
Understanding How the Joystick Device Driver Works
The pre-emptive multi-tasking nature of OS/2 can cause DOS applications reading the game adapter port to deduce incorrect positions for the joysticks connected. The solution to this potential inaccuracy, implemented in the joystick device driver, is to regularly sample the game adapter port inside the Physical Device Driver (PDD) and then return fabricated values to the DOS application that reflect that state. With the logic for regular sampling already in the PDD, it is simply a matter of activating the procedure.
Before any of this can be initiated, however, access to the game port by the DOS application must first be trapped. Whenever I/O ports are to be trapped or emulated, an OS/2 Virtual Device Driver (VDD) is required. The VDD works in conjunction with the PDD to provide the device emulation. The VDD does this by capturing port reads and returning values that reflect the current state as determined by the PDD. The VDD is also responsible for determining whether a given virtual DOS machine (VDM) is to have direct access to the port and, if it is, for obtaining ownership of the VDM.
Virtual Mouse Device Driver
The virtual mouse device driver (VMOUSE) is responsible for all mouse support in the multiple DOS session environment.
Virtual Mouse Device Driver
This chapter describes the virtual mouse device driver (VMOUSE), which is responsible for all mouse support in multiple DOS sessions. The virtual mouse device driver also supports applications that use the BIOS INT 15h ( AH = C2h) pointing-device services.
Some of the most common mouse driver services, available through the INT 33h interface, are listed below:
- Driver-state save, restore, and disable
*Light-pen emulation
*Miscellaneous features
*Position and button-event notification
*Position and button-data tracking
*Selectable pel-to-coordinate and mickey-to-pel mappings
*Video-mode tracking
*Video pointer management (location and appearance)
There are no restrictions on any use of the INT 33h interface, even when a DOS session is in background mode. The only difference between background, focused, and foreground DOS session support is that no mouse events are posted for a background DOS session. Mouse events are posted to full-screen DOS session from the physical mouse device driver, and are posted through the Presentation Manager shield to focused, windowed DOS sessions. The pointer position should remain unchanged as long as a DOS session is in background mode, unless an application initiates pointer movement of its own. In that case, the virtual pointer position changes but nothing is drawn (not even in virtual video space).
The virtual mouse device driver also supports applications that use the BIOS INT 15h (AH=C2h) Pointing Device services.
INT 33h Support
INT 33h support is provided directly by the virtual mouse device driver. If a DOS session is running in a window (instead of full screen), and is in focus, the physical mouse device driver routes the mouse events to the Presentation Manager single queue device driver, then to the shield, and eventually to the virtual mouse device driver. The virtual mouse device driver then buffers the mouse event as if it were for the full-screen DOS session. When the DOS setting MOUSE_EXCLUSIVE_ACCESS is ON for a windowed DOS session, all mouse events go directly from the physical mouse device driver to the virtual mouse device driver, bypassing the Presentation Manager interface. This property is necessary for those applications that track and draw their own mouse pointer.
Driver-State Save, Restore, and Disable
Services are provided to copy all per-DOS session mouse-state information to an application-defined block and back again. When the driver is disabled , it ignores all INT 33h requests and physical mouse device driver events.
Light-Pen Emulation
Whenever this INT 33h feature is enabled, a virtual mouse device driver INT 10h hook is established, and INT 10h light-pen functions are emulated with mouse position and button data.
Miscellaneous Features
The INT 33h interface provides a function to read-and-reset mouse motion counters, which are simply software counters of total horizontal and vertical mickeys. These counters are simulated within the virtual mouse device driver by taking reported pel movements and converting them to mickeys (based on the current mickey-to-pel ratio). This interface must also provide counts of button presses and releases, and the positions at the time of the last press and release. These are maintained by the virtual mouse device driver without any assistance from the physical mouse device driver.
Position and Button-Event Notification
The INT 33h interface provides services to allow the DOS session to receive call-back notification for selectable motion and button events. These call- backs occur at DOS session task time, and do not involve the physical mouse device driver.
Each time the DOS session is notified of a mouse event, it might have to notify the DOS session's user-defined mouse-event subroutine, depending on whether the DOS session's application has registered the subroutine (by way of an INT 33h function) and what events the caller has asked to be notified of.
A registered subroutine is called by requesting a pseudointerrupt in the DOS session. A simulated interrupt service routine (loaded into each DOS session at creation) immediately EOIs (ends the interrupt) and then proceeds to notify the DOS session's registered subroutine. In order to pick an IRQ that is guaranteed not to conflict with any other virtual device driver, the DOS session queries the physical mouse device driver at initialization for its physical IRQ.
Note:It is not important to have the real mouse IRQ, but simply an IRQ that no other virtual device driver needs.
Movement-only events are coalesced. As an event is posted from the physical mouse device driver, the DOS session compares it with any previous event in the event buffer; if it is a movement-only event, the current event accumulates with the previous event in the buffer. This process continues until a non-movement-only event occurs or the current movement event is simulated, thus reducing interrupt-simulation overhead during rapid event- generation periods.
Position and Button-Data Tracking
Other services within the INT 33h interface allow the DOS session to poll the virtual mouse device driver on the current mouse status. There are also services to return the last button press and also the last button-release event.
Selectable Pel-to-Coordinate and Mickey-to-Pel Mapping
Through the INT 33h interface, the DOS session can control the acceleration of the DOS session mouse pointer by varying both the thresholds and the multipliers. This is managed by the entirely by the virtual mouse device driver, without assistance from the physical mouse device driver, which reports only raw mickey events to the DOS session for full-screen DOS sessions.
For windowed DOS sessions, the PM Shield reports absolute pel mouse events to the virtual mouse device driver The virtual mouse device driver maps the raw delta mickeys to the DOS session's current virtual-coordinate grid.
Video Mode Tracking
The virtual mouse device driver receives notification of video mode changes from the virtual video device driver, so that the pointer size and bounds can be appropriately set.
The virtual mouse device driver must be notified of changes in the physical dimensions of the screen. It uses that information to map the raw mickeys into pel coordinates. The virtual device driver uses a device-independent interface to notify the virtual mouse device driver of mode changes so that the virtual mouse driver is capable of supporting any video device without code changes.
Video Pointer Management
The virtual mouse device driver tracks the pointer location, and whether or not the pointer is visible. The actual drawing and hiding of the pointer, however, is handled by the virtual video device driver.
Interfaces are provided by the virtual video device driver to the virtual mouse device driver to perform the following operations:
Define pointer This describes the desired pointer shape and always is issued prior to making a pointer visible for the first time. An error might be returned if the virtual video device driver does not provide pointer support for the current video mode, thus permitting the virtual mouse device driver to skip further drawing and moving requests. The virtual video device driver refuses calls it cannot support.
Draw pointer A position, in pel coordinates, is provided. For text modes, the virtual video device driver maps chunksof pels to individual character locations. The size of a chunk is 8 pels x 8 pels, unless the mode is 40- column, in which case the chunk size is 16 pels x 8 pels. A video page parameter is provided to support the INT 33h SetCRTPage service. Draw requests without intervening Remove requests are treated as Move requests.
Remove pointer Deletes pointer from the screen.
INT 15h (AH=C2h) Support
All the published Pointing Device BIOS services (INT 15h, AH=C2H) are emulated in the virtual mouse device driver For a complete listing of these services, refer to the IBM Personal System/2 and Personal Computer BIOS Interface Technical Reference.
Virtual Mouse Device Driver Services
For the virtual mouse device driver, the virtual video device driver provides a VDHRequestVDDfunction, as well as several direct interfaces for pointer drawing operations. The following VDHRequestVDDservice is provided :
VDHRequestVDD
(
HVDD hvddVideo,
HVDM hvdm,
INT iFunc, /* Virtual video device driver EVREQ_POSTMOUSE (4) */
PVOID pReqIn, /* Undefined. */
PVOID pReqOut /* Undefined. */
); /* Returns TRUE. */
The virtual mouse device driver must return the address of a function that permits the virtual video device driver to obtain mouse position and button status during processing of the INT 10h, Query Light Pen function, when light pen emulation is enabled for the active DOS session. Also, whenever the DOS session changes video modes (including the initial mode change that takes place during DOS session creation), the virtual video device driver notifies the virtual mouse device driver of the new mode and screen dimensions.
Virtual Touch Device Driver
The virtual touch device driver (VTOUCH) provides support for the INT 7Fh in multiple DOS sessions. This virtual device driver is limited (by default ) to making actual touch XYZ data available only to full-screen DOS programs because the physical device driver, which handles the touch data interrupts, cannot determine which window to send the touch data to when running with the Presentation Manager session in the foreground.
In contrast, the physical mouse device driver can determine which window to send the mouse data to because it is able to feed the single queue of the Presentation Manager. The Presentation Manager can then determine, based upon the event XYZ data, which window is to receive the event. If the window is a DOS window, it calls the virtual device driver.
For those DOS applications that receive full screen XYZ touch data while running in a window, the DOS setting TOUCH_EXCLUSIVE_ACCESS is provided. This DOS setting effectively turns off mouse emulation and directs all touch data to that window. The (now device-independent) INT 7Fh continues to function in a window. However, touch data is not available to the application until it is switched to full screen. In all other respects, the application functions exactly as before.
DOS mouse applications are not subject to this restriction because they can run in a windowed or full screen DOS session with touch input in the form of emulated mouse data.
INT 7Fh Support
To access the touch-sensitive display device, DOS applications use the software interrupt 7Fh (INT 7Fh) interface. OS/2 applications use the Tou xxxAPI. The virtual touch-sensitive device driver provides this by using a standard DOS session software interrupt hook. This virtual device driver runs in protect mode (which allows it to share code in all DOS sessions) and virtualizes all the hardware-dependent features that the INT 7Fh interface provides (for example, changing thresholds).
In addition to the touch-sensitive device capability, it is also possible to use the touch-sensitive display to emulate the IBM* mouse. In this case, the standard mouse INT 33h API (for DOS) is used.
Note that only DOS sessions running full screen can obtain full touch XYZ data. Windowed DOS sessions running under Presentation Manager are restricted to emulated mouse data. A DOS touch application that started as full screen stops receiving touch data if it is switched to a window, and starts receiving data again if it switched back to full screen. Conversely, a DOS touch application that is started in a window does not receive data until it is switched to full screen, and does not stop receiving data until it is switched back to a window.
Discussion
A virtual video device driver is used by OS/2 as a virtual display device for DOS applications executing in a DOS session, by providing virtual hardware support. Virtual video device drivers are required when it is necessary for multiple DOS sessions to share one or more video devices.
The virtual video device driver manages access to video memory, video registers, and video adapter ROM BIOS Special functions have been defined to permit other OS/2 Ring 3 components (such as the DOS Session Manager and the Presentation Manager display device driver) to obtain the vital video state information necessary to window a DOS session on the Presentation Manager desktop.
For simplicity, a dedicated virtual video device driver should be targeted to a specific video device. This reference manual includes a set of virtual video device drivers that can be used as templates for enhancement modifications to any of the currently supported devices, or they can be used as samples to create a virtual device driver from scratchfor a similar but compatible device. For example, the OS/2 virtual Super VGA device driver (VSVGA.SYS) is a derivative of the virtual VGA device driver (VVGA.SYS).
The following virtual video device drivers, which cover an extensive range of the most commonly used video devices, are included in this reference manual:
/-----------------------------------------\ |Virtual CGA device driver|VCGA | |-------------------------+---------------| |Virtual EGA device driver|VEGA | |-------------------------+---------------| |Virtual MONO device |VMONO | |driver | | |-------------------------+---------------| |Virtual VGA device driver|VVGA | |-------------------------+---------------| |Virtual XGA* device |VXGA | |driver | | |-------------------------+---------------| |Virtual SVGA device |SVGA | |driver | | |-------------------------+---------------| |Virtual 8514/A device |V8514A | |driver | | \-----------------------------------------/
The video devices for which the OS/2 provides virtual video device drivers include:
- Western Digital**
*ATI**
*Cirrus Logic**
*Headland Technology**
*Trident** .
*Tseng**
*Video 7**
Note:Specific Super VGA chip revision and model support can be found in VVDP.H.
Installable Virtual Video Device Driver Architecture
The architecture of a virtual video device driver adheres to the architecture defined for all virtual device drivers. However, some parts of the multiple DOS sessions architecture have been designed primarily for virtual video device drivers, as follows:
- Foreground and background notification hooks
*Freezeand thawservices
*Title change and code-page change notification hooks
A significant amount of the primary virtual video device driver code involves communication with the DOS session Window Manager. A Remote Procedure Call (RPC) mechanism must be used to communicate between the DOS session Window Manager and a virtual video device driver under the following conditions:
- The DOS session Window Manager is a Ring 3 component (lowest privilege level)
*Virtual device drivers run at Ring 0 (highest privilege level)
*DOS sessions have no Local Descriptor Table (LDT), and therefore cannot attach to Dynamic Link Libraries (DLLs)
For this purpose the DOS session Window Manager creates a thread that calls the virtual video device driver to wait for a video event from any of the currently windowed DOS sessions.
Design of Installable Virtual Video Device Drivers
A virtual video device driver is a basedevice driver, although a "DEVICE=" statement in the CONFIG.SYS file is used to specify one or more virtual video device drivers to load. The DOS session Manager and DOS session Window Manager identify a virtual video device driver by its registered name. For example, a virtual video device driver for the primary display would register as VVIDEO1$, a virtual video device driver for the secondary display device would register as VVIDEO2$, and so forth.
Note:Support of multiple DOS sessions is disabled if no virtual video device driver claims ownership of the primary display device after virtual video device driver loading and initialization is completed.
Supporting DOS-Standard Adapters and Modes
IBM-compatible CGA, EGA, VGA, XGA, and 8514/A adapters are supported as primary display devices; monochrome adapters are supported as secondary display devices. For these devices, the standard configurations (including the amount of video memory, type of monitor and so forth), are supported. However, there are a few exceptions. For example, other dual-adapter combinations such as EGA/monochrome with CGA/color, or VGA/monochrome with CGA/color are not supported.
All EGA monitor combinations (RGB, ECD, and monochrome) and VGA, XGA, 8514/ A monitor combinations (i512/8513, 8514, and 8515), as well as all EGA memory combinations (64KB, 128KB, 192KB, and 256KB) of the 8514/A monitor are supported. The type of monitor used with a monochrome or CGA adapter is immaterial; that is, the behavior of the adapter is not affected.
There are some limitations, however. For example, an EGA, VGA, or Super VGA with a 2xxport configuration, instead of the standard 3xxconfiguration, is not supported. Also, an EGA display with only 64KB of display memory cannot support high-resolution graphic modes in a window, due in part to the video mode used concurrently by Presentation Manager (640 x 200, 16 colors), which consumes nearly all of the 64KB of on-board video memory. In addition, blinking attributes (whether in text or graphics modes) cannot be emulated in a DOS window.
A significant portion of the primary virtual video device drivers involves communication with the DOS session Window Manager. This includes providing a set of services to fully describe a DOS session's video state and a set of notifications to signal when the video state changes, so that a DOS session being windowed remains relatively synchronized with its associated DOS session that is executing in the background.
Because the DOS session Window Manager, OS/2 Session Manager, and Presentation Manager display device driver execute in Ring 3, and while the virtual video device driver runs in Ring 0, a system entry point is necessary for these Ring 3 components to communicate with the virtual video device driver. The virtual video device driver provides the following DosRequestVDDservice to:
- DOS session Window Manager
-Set Access
-Set Focus
-Set Lock
-Query Mode Info
-Query Cursor Info
-Query Palette Info
-Copy LVB Content
-Copy Bit Map Content
-Wait for Video Event
-Control Event
*PM Display Device Driver
-Set Display Requirements
-Request off-screen VRAM
-Free off-screen VRAM
-Request VGA Controller
-Free VGA Controller
-Query VRAM Status
Note:See the Display Device Driver Referencefor a detailed explanation of the DosRequestVDDfunctions provided by the virtual video device driver.
There are two kinds of DOS session window support:
- Displaying a running image in a window
*Displaying a frozen image in a window
The latter is a subset of the former. The virtual video device driver always attempts to provide support for displaying a running image and for standard text and CGA graphics modes this is always possible, but there are graphics modes cases where that is not possible. One example is the 64KB EGA mode; other examples are the XGA and 8514/A modes.
Support for the XGA or 8514/A graphics modes is not a matter of sufficient memory but of the sheer complexity of virtualizing the 8514/A hardware. In addition, if a DOS application uses VGA graphics modes on an 8514/A system, it will not be able to use the VGA memory if a monitor being used as a secondary display by other tasks in the system is connected to the VGA.
There is no known, reliable method of determining whether a monitor is connected to the VGA or Super VGA. The 8514/A can detect a limited set of IBM-compatible, fixed-frequency monitors whereas the XGA, using DMQS, has the potential of identifying all monitor types, including OEMs.
In an 8514/A system, there is no architected way for the virtual video device driver to determine whether the VGA is in use by another process or session. Conversely, there is no way for the virtual video device driver to claim the device and prevent other processes or sessions from later acquiring the device.
Notes:
1.256-color modes will not be accurately rendered in a window even when the PM display driver supports 256 colors, because the DOS session Window Manager does not provide Palette Manager support.
2.High-resolution graphics modes on a 64KB EGA currently will not be rendered properly in a DOS window because the memory organization is substantially different (planes 0 and 1 and planes 2 and 3 are chained together).
OS/2 provides a single, generic Super VGA virtual device driver that supports the majority of the Super VGA video adapters made with the above- mentioned Super VGA chip sets. However, there are a small number of adapters that cannot be reliably virtualized, due to the way they are designed. For example, adapters that require multiple OUTs to a specific port before permitting the extended clock bits to be programmed fall into that category.
Of the 8514/A graphics modes, only the 1024 x 768 256-color mode has been tested for accurate rendering in a window.
Virtual Video Device Drivers
The following list contains the installable virtual video device drivers that are included with the Developer's Tooklkit for OS/2:
- Virtual CGA device driver (VCGA)
*Virtual EGA device driver (VEGA)
*Virtual MONO device driver (VMONO)
*Virtual VGA device driver (VVGA)
*Virtual XGA device driver (VXGA)
*Virtual 8514/A device driver (V8514A)
The architecture of the virtual video device driver adheres to the architecture defined for all virtual device drivers. However, some portions of the multiple DOS session architecture have been designed primarily for ( or used by) virtual video device drivers:
- Foreground and background notification hooks
*Freeze and thaw services
*Title change and code-page change notification hooks
A significant portion of the primary display virtual device drivers involves communication with the DOS session Window Manager. This includes providing a set of services to fully describe a DOS session's video state and a set of notifications to signal selected changes in state, so that a window remains relatively synchronized with its associated DOS session.
Discussion
Because the DOS session Window Manager is a Ring 3 component, virtual device drivers run at Ring 0, and DOS sessions have no LDT (and therefore cannot attach to DLLs), a Remote Procedure Call (RPC) mechanism must be used to communicate between the DOS session Window Manager and a virtual device driver. The DOS session Window Manager creates a thread for this purpose, which calls the virtual video device driver to wait for a video event from any of the currently windowed DOS sessions.
Virtual video device drivers are base device drivers. "DEVICE=" statements in the CONFIG.SYS files are used to specify one or more virtual video device drivers to load. The DOS session Manager and DOS session Window Manager identify a virtual video device driver by its registered name (for example, a virtual video device driver for the primary display device would register as VVIDEO1$, one for the secondary display device would register as VVIDEO2$, and so forth). After virtual video device driver loading and initialization is complete, if no virtual device driver has registered for the primary display device, multiple DOS session support is disabled.
IBM-compatible CGA, EGA, VGA, XGA, and 8514/A adapters are supported as primary display devices, and MONO adapters are supported as secondary display devices. For these devices, all the standard configurations (that is, amount of video memory, type of monitor, and so forth) are supported. However, there are a a few exceptions. For example, support for other dual- adapter combinations, such as EGA/monochrome with CGA/color, or VGA/ monochrome with CGA/color, are not specifically supported. In addition, all EGA monitor combinations (RGB, ECD, and monochrome), EGA memory combinations (64KB, 128KB, 192KB, and 256KB), VGA and 8514/A monitor combinations (8512, 8513, and 8514), and VGA and XGA monitor combinations ( 8512, 8513, 8514, and 8515) are supported. The type of monitor used with a monochrome or CGA adapter does not affect the behavior of the adapter.
Virtual and Nonvirtual Operation
For optimal performance and compatibility, the virtual video device drivers support full-screen operation. In this mode, there is no visual difference between DOS and DOS session operation. For convenience, an option appears on the DOS session system menu to convert the DOS session from windowed mode to full-screen mode and back. Virtual video device drivers support full-screen operation by performing the following operations:
- Registering foreground and background VIDEO_SWITCH_NOTIFICATION hooks with the DOS session Manager
*Allocating a save and restore video buffer
*Installing I/O hooks to shadow key video port accesses
*Mapping physical video memory into the appropriate video address space
*Compelling text-mode fonts to match the currently selected code page
*Providing pointer drawing services to the virtual mouse device driver to define, draw, and erase pointer images
When a DOS session does not own the physical display (that is, when it is background), the virtual video device drivers:
- Install I/O hooks to track and emulate all video port accesses.
*Map appropriate system memory to the active portions of the video address space.
*Report video events to the DOS session Window Manager (assuming the Presentation Manager is active and the DOS session is an unminimized window ). This includes changes to:
-Mode
-Palette
-Cursor
-Video memory
-Input events
-Scroll or string events
-Paste continue or terminate (through the virtual keyboard device driver)
-Session title change
-Screen-switch or video memory allocation errors
At any time, the DOS session Window Manager (or other processes that have access to a DOS session's process ID) can update a DOS session's window state:
- Windowed or nonwindowed
*Focus or nonfocus
*Minimized or unminimized
*Lock or unlocked
as well as query any aspect of a DOS session's video state:
- Mode
*Palette
*Cursor
*Video memory
*Wait for video events
*Cancel wait for video event
Mouse-Independent Pointer Drawing Services
When the virtual video device driver creates a DOS session for the first time, it opens the virtual mouse device driver. If the open is successful, it provides the virtual mouse device driver with the following entry points :
- Show Pointer
*Hide Pointer
*Define Text Pointer
*Define Graphics Pointer
*Set Video Page
*Set Light-Pen Emulation
Also, whenever the DOS session changes video modes (including the initial mode change that takes place during DOS session creation), the virtual video device driver notifies the virtual mouse device driver of the new mode, the screen dimensions, and so forth.
Built-in Extended INT 10h and INT 2Fh Services
The EGA register interface is integrated into the virtual video device driver as part of its INT 10h interception logic. This interface is a set of INT 10h services that are used by applications to make drawing operations and simultaneous use of the mouse pointer possible on EGA and VGA hardware. The virtual video device driver's pointer drawing services are intended to replace this interface, but existing graphical applications still use it (generally when mouse support is also present), so the interface must be present or these applications will not function correctly .
The INT 2Fh services notify applications when they are about to be switched to full-screen or background mode. Applications can use this notification to stop accessing video memory, if they are using a video memory not supported for background operation. This will prevent them from freezing, and also redraw their screen in the event the virtual video device driver fails to fully restore it.
Summary of the 8514/A and XGA Virtual Device Drivers
DOS applications currently written to the 8514/A Adapter Interface (AI), the XGA AI, or directly to the 8514/A and XGA display adapters are able to run in a full-screen DOS session. This is due to the ability of each adapter's virtual device driver to:
- Grant I/O privilege
*Save or restore the video state
*Provide video bitmap images to the shield layer when the DOS session is being windowed
A DOS application is allowed to run only in a full-screen foreground DOS session, and is immediately frozen if it attempts to access the hardware when switched to the background.
The virtual 8514/A device driver statements, which are required in the CONFIG.SYS file, are added during installation when the presence of an 8514 /A display adapter is noted:
DEVICE=C:\OS2\MDOS\VVGA.SYS
DEVICE=C:\OS2\MDOS\V8514A.SYS
The virtual XGA device driver statements, which are required in the CONFIG. SYS file, are added during installation when the presence of an XGA display adapter is noted:
DEVICE=C:\OS2\MDOS\VVGA.SYS
DEVICE=C:\OS2\MDOS\VXGA.SYS
The following items should be set in DOS to enable a DOS session:
- Enable I/O trapping to permit the virtual video device driver to save and restore the hardware instance used by a DOS application when the application switches away from the foreground DOS session. The virtual video device driver allocates a buffer to save the video image. The maximum size of this buffer is 1MB and is obtained each time a full-screen DOS session is created.
Enabling I/O trapping is the default. Although multiple instances of XGA can be present on a system, the virtual XGA device driver saves or restores only the state of the first instance used by a DOS application. It is the application's responsibility to save or restore the other XGA instances.
- Register for screen switch notification. This implies that a DOS application has hooked INT 2Fh so as to be notified when it is to be switched to full-screen foreground or background. This notification informs the application that it must restore the screen when switched to full- screen foreground, and must stop accessing video memory (to avoid freezing) when switched to background.
An application that uses more than one instance of XGA must specify this option to save and restore the states of the other XGA adapters. The default is no VIDEO_SWITCH_NOTIFICATION.
Any DOS session that is not saved or restored by the virtual video device driver cannot be displayed in a window. DOS 8514/A and XGA applications are not interactive in a window; they can only be viewed.
OS/2 Version Compatibility Considerations
The following table lists information that has been added to or changed in this documentation since the availability of OS/2 Warp, Version 3. When writing a device driver, you will want to take into consideration these particular changes, which may affect the downward compatibility of these items.
/--------------------------------------------------------------\ |Item Added or |Date Item Added or |Compatibility of | |Changed |Changed |Addition or Change | |--------------------+--------------------+--------------------| |Advanced OS/2 |November 1995 |OS/2 Warp, Version 3| |Joystick Device | |and higher | |Driver | | | \--------------------------------------------------------------/