VDDR/2 - Virtual Device Driver Architecture and Operations
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation
|Virtual Device Driver Reference for OS/2|
|Part 1. Overview
Part 2. Virtual Device Drivers
Part 3. Reference Material
- 1 Virtual Device Driver Architecture and Operations
- 1.1 Virtual Device Driver Architecture
- 1.2 Virtual Device Driver Operations
- 1.2.1 Virtual Device Driver Loading
- 1.2.2 Virtual Device Driver Initialization
- 1.2.3 DOS Session Creation and VDD Per-DOS Session Initialization
- 1.2.4 Local and Global Information Regions
- 1.2.5 Virtual DevHlp (VDH) Services
- 1.3 Inter-Device-Driver Communication
- 1.4 Hardware Emulation and Interrupt Support
- 1.5 Interrupts Supported by Multiple DOS Sessions
- 1.5.1 BIOS Hardware Interrupt Support
- 1.5.2 BIOS Software Interrupt Support
- 1.5.3 DOS Software Interrupt Support
- 1.5.4 Other Software Interrupt Support
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 swappable or 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. Base virtual device drivers are those that must be present for multiple DOS sessions to function. Installable virtual 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 virtual state 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 VDHInstallUserHook for a complete list of user hooks.
Installing User Hooks
Each virtual device driver must use VDHInstallUserHook to 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 VDHGetError returns 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:
See C Language Virtual DevHlp Services for a list of the page-granular memory management services and a description of each virtual DevHlp.
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 VDHOpenPDD service 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 VDHOpenPDD for 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, VDHOpenPDD, 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)
VDHPushInt calls 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 VDHArmReturnHook service allows the IRET to be hooked after the VDHPushInt service 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 VDHArmContextHook and 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 chaining indication, 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. VDHPushInt is 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 hooks are 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/2 for more information.
- IRQ 11 Reserved. A virtual device driver to simulate this hardware interrupt is not provided. See #Reserved IRQ Support in OS/2 for further information.
- IRQ 12 Auxiliary Device. A virtual device driver to simulate this hardware interrupt is not provided. See #Reserved IRQ Support in OS/2 for 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 Reserved and Redirect Cascade interrupt 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+PrtScr keystroke 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:
- 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 Guide are 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.0 are 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.0 are available.