Virtual Device Drivers for MS-DOS Applications or Special Hardware

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.

Microsoft® Windows NT® 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 Windows NT system. The VDM environment serves programs such as:

·MS-DOS applications

·16-bit drivers

·16-bit Windows applications (WOW)

·Terminate and stay resident (TSR) programs

Windows NT launches the VDM as necessary to support MS-DOS applications launched by the user. There may be several copies of the VDM running at any one time in a Windows NT system. There is one copy of the VDM to support all Windows 3.x applications launched by the user. In addition, each console session (MS-DOS Shell) can initiate a VDM if the user launches an MS-DOS application from that session. Multiple copies of the VDM each set up a self-contained virtual DOS machine. They do not interfere with each other, so there are never resource conflicts among the copies.

When the VDM is launched, it:

·Allocates memory in which to create a virtual DOS machine.

·Reads the files \system32\config.nt and \system32\autoexec.nt.

·Loads drivers and executes batch files as specified.

·Loads the application and executes 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 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 illustration.

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.

In Windows NT, 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 Windows NT does not permit the real-mode addressing techniques of DMA to the board.

To support an MS-DOS application using special hardware in the Windows NT 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 by using the system services provided by Windows NT.