|
|
|
Note A VDD need only be written to support special-purpose hardware devices that operate under an MS-DOS® application. The provided VDM has built-in support for commonly used hardware such as serial communication ports, video, mouse, and keyboard. Consequently, you should not need a VDD to virtualize access to these common devices.
The NT-based 32-bit operating system provides a virtual DOS machine (VDM) within the Microsoft® Win32® subsystem to support real-mode and protected-mode MS-DOS applications. The VDM creates an environment where unmodified 16-bit MS-DOS binaries can execute without threatening the security and integrity of the 32-bit system. The VDM environment serves programs such as:
The NT-based operating system launches a VDM as necessary to support 16-bit applications launched by the user. There can be several VDMs running at any one time, each in its own process. Every VDM sets up a self-contained virtual DOS machine environment. Each individual VDM is dynamically configured to run either a Windows 3.x application or an MS-DOS application. When any Windows 3.x application is launched, the VDM in which it runs loads the WOW subsystem, which is a simulation of the Windows® 95 16-bit environment. Any Windows 3.x application can run either in a separate VDM or in the default shared-WOW VDM. In addition, a console session launches a VDM whenever the user starts an MS-DOS application from the command prompt.
When the VDM is launched, it:
The application runs as it would in a native MS-DOS environment because the VDM provides virtual equivalents of all the functionality MS-DOS would supply to the application. All drivers and batch files execute within the virtual DOS environment set up by the VDM.
Given the functionality of the VDM, most MS-DOS applications can run without any modification or additions in the Windows NT/Windows 2000 environment. However, there are some MS-DOS applications that depend on custom hardware, such as a fax board or a 3270 communications board. Generally, these applications have a plug-in hardware board they manipulate directly through 80386/80486 I/O port IN and OUT instructions and by writing directly to memory on the board. These applications might also use DMA to transfer data to and from the board. In an MS-DOS environment, these operations allow the application or its 16-bit driver to get direct access to the hardware device, as shown in the following figure .
Normal MS-DOS hardware device access
In an MS-DOS system, an application can perform these operations directly. In some cases, the application uses a 16-bit device driver or a TSR to communicate with the hardware. The application makes calls to the driver or calls the TSR through a software interrupt. For the purposes of this document, the 16-bit driver or TSR is considered to be an extension of the application that requests services. Thus, when this document talks about an MS-DOS application, it refers to either an MS-DOS application that manipulates a hardware device directly, or to a combination of an MS-DOS application and a 16-bit driver or TSR that manipulates the hardware.
On the NT-based operating system, MS-DOS application programs (and 16-bit drivers or TSRs) do not have sufficient processor privilege to use 80386/80486 I/O ports, and the virtual addressing mode of the system does not permit the real-mode addressing techniques of DMA to the board.
To support an MS-DOS application using special hardware in an NT-based 32-bit environment, the application developer must write a 32-bit kernel-mode device driver to access the board hardware. The developer must also write a VDD to translate operations performed by the MS-DOS application into the corresponding kernel-mode device driver calls for the particular board. The paired kernel-mode device driver and VDD for the device enable the original MS-DOS application to run in the VDM layer.
In addition to I/O port and memory access arbitration, a VDD can also support DMA, register manipulation, translation of real-mode addresses to 32-bit full pointers, and hardware interrupt simulation. The following sections describe how to write a VDD.