Virtual devices support all hardware devices for a typical computer, including the programmable interrupt controller (PIC), timer, direct-memory-access (DMA) device, disk controller, serial ports, parallel ports, keyboard device, and display adapter. A virtual device is required for any hardware device that has operating modes that can be set or retains data over any period of time. In other words, if the state of the hardware device can be disrupted by switching between multiple applications, the device must have a corresponding virtual device.
Many hardware devices use interrupts to signal when data is ready or the device is available. Virtual devices rarely intercept these hardware interrupts directly. Instead, a virtual device relies on the virtual programmable interrupt controller device (VPICD) to process hardware interrupts. The virtual device installs a callback procedure which the VPICD calls when a hardware interrupt occurs. The callback procedure typically services the interrupting device, or requests the VPICD to reflect the interrupt into the ROM BIOS or other code that services the device. A virtual device can also register callback procedures to handle other phases of interrupt processing such as the execution of the iret instruction. Virtual devices must not modify descriptors in the interrupt descriptor table (IDT).
Most hardware devices provide memory-mapped or I/O-port registers through which applications can set the operating mode of the device and read or write data. Virtual devices typically trap access to these registers to record changes to the state of the device and to simulate the reading or writing of data. If a hardware device uses memory buffers, such as video memory for a display adapter, the virtual device usually takes ownership of the physical memory to prevent the system from attempting to use it. The virtual device also maps the memory to prevent applications that run in the background from overwriting the current contents.
Many hardware devices have corresponding ROM BIOS or installable device driver routines (collectively called the API) that set and record the state of the device. In most cases, applications call these routines by using a software interrupt. Virtual devices usually install callback procedures to intercept these software interrupts. This allows the virtual device to either simulate the requested action, or prepare the parameters in the call for execution in V86 mode. Preparing parameters (called API translation or mapping) is required when a protected-mode application passes an address to a ROM BIOS or device driver routine that runs in V86 mode.
Some virtual devices support software, but no corresponding hardware device. For example, the virtual shell device provides access to the Windows MessageBox function. In general, a virtual device can provide any kind of services for the VMM and other virtual devices. It can also provide API functions for V86 and protected-mode applications. These API functions potentially give 16-bit applications direct access to the features of the virtual device.