 |
|
|
|
|
|
|
|
|
 |
 |
 |
 |
|
||||
 |
 |
 |
 |
 |
 |
|
||
FAQ: How Virtual Device Drivers (VDDs) WorkVDDs are Win32 DLLs with specific entry point and installation requirements. They allow 16-bit applications (DOS and Win16 applications) to access certain I/O ports, be informed of certain device interrupts, and so on, when running under Windows NT. By "certain", we mean those without security ramifications: 16-bit applications running under NT are allowed to access devices such as serial and parallel ports, but not the disk controller. Note, however, that VDDs do not actually access I/O hardware from user mode. They simply provide routines that the NTVDM calls after trapping a 16-bit app's attempts to reference IO ports. The actual I/O hardware access is done by an ordinary NT kernel mode driver. Virtual Device Drivers work like this: When NT runs a DOS or Win16 application, it does so by first running a Win32 console application, NTVDM.EXE. NTVDM maps the DOS or Win16 app into its own process's address space and transfers control to it in real mode. If the 16-bit code tries to issue an IN or OUT instruction, the attempt raises an exception, just as does any IN or OUT instruction issued from user mode under NT. This is because NT sets up the x86 I/O Privilege Mask (IOPM) to allow I/O port access (for all ports) only from ring 0, or as NT calls it, kernel mode.
NTVDM traps the exception,
notices that it's the result of an attempt to reference
an I/O port from the 16-bit app,
and checks to see if a VDD exists that can handle the port in question.
If so, NTVDM calls routines within the VDD.
These routines in turn issue standard Win32 VDDs can also allow a 16-bit application access to certain INT-requested BIOS functions and can allow them to be notified of interrupts from certain devices. top of page | up | previous | next | home |
|
|||||||