Design and implementation of virtual device driver

Because Windows has a masking strategy for the underlying operation of the system, the system becomes more secure for users, but this poses a lot of difficulties for many hardware or system software developers, as long as the underlying operations are involved in the application Developers have to dive into the Windows kernel to write virtual device drivers that are part of the system level. The mechanism of WIN 98 is different from the win 95 device driver, and win 98 supports not only the Windows NT 5.0-compliant WDM (WIN32 Driver mode) mode driver, but also the WIN 95 compliant virtual device driver VxD Device Driver). The basic principle and design method of the virtual device driver VxD based on the Windows 9x platform are introduced, and a design example of a virtual device driver VxD for Videophone audio card is given in combination with the development tool VTOOLSD.

1. Virtual Environment for Windows 9x

Windows 9x, as a complete 32-bit multitasking operating system, is not dependent on MS-DOS like window 3.x, but in order to ensure software compatibility, Windows 9x, in addition to supporting WIN16 applications and WIN32 applications, You also have to support the operation of MS-DOS applications. Windows 9x ensures its compatibility and multi-tasking characteristics through a virtual machine VM (Machine) environment.

The so-called Windows virtual machine (often referred to as a Windows VM) is the virtual environment that executes the application, which includes the MS-DOS VM and the system VM two virtual machine environments. Only one MS-DOS process is running in each of the MS-DOS VMS, and the system VM can provide a running environment for all Windows applications and dynamic link library DLLs (dynamically link libraries). Each virtual machine has a separate address space, a register state, a stack, a local descriptor chart, an interrupt table state, and execution precedence. Although Win16, Win32 applications run in the system VM environment, WIN16 applications share the same address space, and WIN32 applications have their own separate address space.

When writing applications, programmers often ignore the differences between virtual and real environments, which are generally considered virtual environments. However, you cannot do this when writing a virtual device driver VxD, because the job of the VxD is to provide the application code with an environment for the hardware interface, manage the status of virtual devices for each client VM, transparently arbitrate multiple applications, and access the underlying hardware. This is called the concept of virtualization.

A VxD runs under the control of Virtual Machine Manager VMM, and VMM is actually a special VxD. VMM performs work related to system resources, providing a virtual machine environment (capable of generating, scheduling, uninstalling VMs), scheduling multi-threaded preemptive time slices, and managing virtual memory. VXD and VMM run outside of any other virtual machine, VxD is actually part of the software that implements the virtual machine.

Like most operating systems, Windows adopts a hierarchical architecture. VMM and VxDs constitute the RING0-level system core of Win 95 (the application runs at the ring3 level, ring1, ring2 level is not used) and has the highest priority of the system. Windows also provides a number of "DRV" as the suffix name driver, mainly refers to the serial port of the communication program and the parallel port of the printer program. These programs are different from VxD, and they are run at the ring3 level.

2. Deep understanding of VMM and VxD

As mentioned earlier, VXD is the abbreviation for Virtual Device driver, but it is understood as a dummy driver. In fact, a VxD is not just a device driver for a specific piece of hardware that is virtualized. For example, some VxD can virtualize devices, and some VxD as device drivers do not virtualize the device, and some VxD has nothing to do with the device, it only serves other VxD or applications.

A VxD can be statically loaded with VMM or dynamically loaded or unloaded as needed. It is precisely because of the close collaboration between the VxD and VMM that the VxD has the capabilities that the application does not have, such as unrestricted access to hardware devices, arbitrary viewing of operating system data structures (such as descriptors, page tables, and so on), access to any memory area, capturing software interrupts, capturing i/ O port operations and memory access can even intercept hardware interrupts.

Although the VxD uses the 32-bit flat storage mode (flat memory model), its code and data use segmented management, and there are six types of segments, namely real mode initialization, protected mode initialization, paging, non paging, static and debug only (debug only), Each type has a section of code and data, so there are 12 paragraphs in the VxD. Real-mode code snippets and data segments are 16-bit (segmented mode), while other segments are 32-bit (planar mode). The "Real Mode Initialization" section contains code to be executed before VMM becomes protected mode during the initial phase of the Windows initialization process. Statically loaded VxD at this point, you can view the real-mode environment before Windows starts, decide whether to continue loading, and notify VMM. After loading, VMM enters protection mode and executes the protection mode initialization code, which also notifies the VMM of execution results. When initialization is complete, the "Real Mode Initialization" section and the "Protected mode initialization" section are discarded. Most of the code for a VxD is in some other section, the pagination section allows virtual Memory Manager to manage paging, and most of the VxD code should be in the pagination section. The contents of the non-pagination section mainly include: The main entry point of the VXD, the hardware interrupt handler, the data accessed, and the asynchronous service that can be called by another VxD interrupt handler function. The "Static" segment is only for VxD that can be loaded dynamically, and when the VxD is unloaded, both the static code snippet and the data segment remain in memory. The "Debug only" segment is just a VMM that is loaded in a debugging environment such as Soft-ice for Win 95.

VMM is identified by the device description of the VxD at Descriptor DDB (Device descriptor block). DDB provides VMM with the main entry point for the VxD, as well as an entry point for applications and other VxD. VMM uses this main entry point to notify the VxD of VM and Windows itself, and the VxD responds to these events by working accordingly. Since VxD does not only serve a physical device (such as multiple serial ports) or only contact a VM, a VxD needs to generate its own supported data structures (supporting data structures) to hold the configuration and status information for each device, each VM. VXD uses one or more device context structures to hold device information, such as the I/O port base address, interrupt vectors, and so on, and the VxD keeps the state information of each VM in the VMM's VM control block.

The services provided by VMM include: event services, memory management services, compatible execution and protection mode execution services, logon table services, dispatcher services, synchronization Services, debugging services, I/O capture services, processing errors and interrupt services, VM interrupts and callback services, Configuration Manager services, and other miscellaneous services.

The above covers only a small part of the VxD design, as a VxD developer must have more knowledge. The first is the knowledge of the operating system, such as address space, execution context, resource lock, interprocess communication and asynchronous event processing, and so on, second, the Intel processor should have a deeper understanding, including registers, machine instruction set, protection mechanism, paging mechanism, and virtual 8086 mode; You must also familiarize yourself with the various services and interfaces provided by VMM and familiarize yourself with Windows other system VxD.

3. Introduction to Development tools VTOOLSD

VTOOLSD is a tool software that specializes in developing VXD programs, including the VxD Framework code generator Quickvxd, C run-time Library, Vmm/vxd Service library, VxD C + + class libraries, vxdload and Vxdview utilities, and a large number of C, C + + routines. The VXD program generated by VC + + and bc++ 32-bit compiler can run out of the VTOOLSD environment.

Using Quickvxd can easily and quickly generate a VxD framework, that is, to generate a suffix named H, CPP and mak three files. The source file contains the basic components that run the VxD, including function frameworks that control message processing, API entry points, and VxD services, and also define flags, set compilation parameters, declare classes, and then add your own code to the generated individual processing functions in the C + + environment. Finally, the standard VxD program is generated using compiler nmake.

Because the VxD runs at the RING0 level, debugging the program is quite difficult. The debugging tool I'm using is soft-ice for Win 95.

The latest version of VTOOLSD is 3.0, which supports device Access architecture DAA (Device access architecture), and the program code written will be available on all Windows platforms (including Win 95, win 98, and Windows NT) is shared on. Of course, you can also use Microsoft's DDK (Device Developer Kit) to develop a VxD, but DDK can't provide rich C-run libraries and C + + class libraries, like VTOOLSD, through the masking system and the underlying technical details of the VXD. Rather, it is convenient and efficient for developers to fully enjoy object-oriented programming methods, so it is not convenient to use DDK for this point alone.