The virtual equipment driver is initially
In this tutorial, I assume that the reader is more familiar with the operation of Intel 80x86 protection models such as deficiency 8086 mode, tag, gdt, ldt, and IDT. If you don't know this, then you have to read the Intel's documentation in http://developer.intel.com/design/pentium/manuals/.
content:
Windows95 is a multi-threaded operating system running in the highest level privilege, Layer 0. All applications run at the lowest privilege, level 3 level. This limits the operation of the application to the system. They cannot use the CPU privilege instruction, which cannot directly access the I / O port, and so on. You must be familiar with the three large system components of GDI32, Kernal32 and USER32. You will definitely think that this important code segment must be running at level 0 level. But in fact, they are in the same way as other applications, are running at the third level. This means that they are not more permissions than the Windows calculator, or the mine game. The control of the system is in the hands of the virtual level manager (VMM) and the virtual device driver (VXD).
It is caused by DOS. In the era of Window 3.x, there are many successful DOS software in the market. Windows 3.x must run a normal Windows program and DOS programs at the same time, otherwise it will lose the market.
This situation is difficult to handle because the DOS program is different from the Windows program. The DOS program considers everything they have system: keyboard, CPU, memory, hard disk, and more. The DOS program does not know how to cooperate with other programs, and the Windows program (from then) is a reliable multitasking system. That is, each Windows program must communicate with other programs through GetMessage or PeekMessage.
Solution is to run all DOS programs on a 8086 virtual machine, and run other Windows programs on another virtual machine called the system virtual machine. Windows is responsible for distributing the CPU calculation time to each virtual machine. This way, in Windows 3.x. The WINDOWS program is used in cooperation multitasking, and the virtual machine is used in a priority multitasking.
What is a virtual machine? A virtual machine is an illusion created by the software. A virtual machine and the program running on it interacts, just like this program is running on the real machine. In this way, a program doesn't know if you don't care whether you are running on a virtual machine. As long as the virtual machine is accurate like a real machine, we can treat it as a real machine.
You can view the interface between the virtual machine's real machine and software as an API. This unusual API consists of an interrupt, BIOS call, and I / O port. If Windows is perfectly simulated with this API, the programs running on the virtual machine will express exactly the same as they run on the actual device.
This is why VMM and VXD will appear. To coordinate and monitor virtual machines (VMS), Windows requires a program to assign tasks. This program is a virtual machine manager (VMM).
Virtual Machine Manager
VMM is a 32-bit protection mode program. Its main task is to establish and maintain a framework that supports virtual machines. For example, it is to create, run, and end a virtual machine. VMM is one of the large system VXD programs that are placed in the VMM32.vxd file in your system directory. The VMM itself is a VXD program, but it is treated as a monitor that monitors other VXD programs. Let's take a look at the starting order of Windows95:
Load IO.SYS. Perform config.sys and autoexec.bat. Call win.com. Win.com runs VMM32.vxd, VMM32.vxd is actually a simple DOS EXE file. VMM32.VXD loads VMM to extend memory with an XMS driver. VMM initializes its own and other default VXD. VMM transfers the machine to the protection mode and creates a system virtual machine. Finally loaded virtual housing devices to start Windows by running KRNL386.exe on the system virtual machine. KRNL386.EXE loads all files, and finally the Windows95 shell. As you can see, VMM is the first VXD program that is loaded into memory. It creates a system virtual machine and initializes other VXD programs. It also provides many services for these VXD programs.
The operation mode of VMM and VXD is different from the real program. Most of the time they are lurking. These VXD programs are not activated when the application runs in the system. They are awakened when some interrupt / error / events that need them handle.
VMM is not rebarned. This means that the VXD program must synchronize their access and VMM service. In some cases, calling VMM services is unsafe, such as VMM is processing a hardware interrupt. During this period, VMM is not allowed to enter. As a VXD writer, you must be extremely careful to your own. Remember, you are at the highest privilege level, level 0 level, if your code is wrong, no one can manage.
Virtual equipment driver
The virtual device driver is referred to as VXD. X represents the names of various devices, such as virtual keyboard drivers (VKDs), virtual mouse drivers (VMDs), and more. The VXD program is a way to successfully initialize the hardware. I remember that the DOS program considers everything that has a system. When they run in a virtual machine, Windows needs to give them a real machine. The VXD program is these substitutes. The VXD program typically virtually some hardware devices, so, for example, when a DOS program considers it to communicate with the keyboard, it is actually a virtual keyboard driver communication with the DOS program. A VXD program typically controls the real hardware device and manages the sharing between the device in various virtual machines.
Despite this, it is not to say that each VXD program must be connected to a hardware device. Although the VXD program is used to virtual hardware devices, we can also view the VXD program as a DLL at the level level. For example, if you need to do some work that can only be done at level 0, you can compile a VXD program to do this for you. This way, since this VXD program does not have a virtual device, you can just see it as an extension of your program.
Before we discuss VXD and create our VXD programs, let me say some things about VXD.
The VXD program is unique to Windows 9X, which cannot be running under Windows NT. So if your program rely on VXD, it cannot be ported to the Windows NT platform. VXD is the largest entity in the system. Since they can do anything to the system, they are extremely dangerous. A malicious / wrong VXD program can destroy the entire system. There is no protection measures for malicious / wrong VXD programs. Usually, there are many ways to achieve your goal without VXD. Before using VXD solution, you must think twice. Use this approach if you use other methods that can be implemented at a level 3 level.
There are two kinds of VXDs under Windows 95:
Static vxd dynamic VXD
Static vxd is the VXD program that is loaded from the system starts and exists in memory before the system is turned off. This VXD can be traced back to the era of Windows 3.x. Dynamic VXD is only available under Windows 9X. Dynamic VXD programs can be loaded / uninstalled when needed. Most of these programs are used to control the installation manager and the plug-and-play device loaded by the input / output monitor. You can load or unload dynamic VXD programs in your Win32 application.
Communication between VXD programs
VXD programs, including VMM, communication with each other through the following three ways: control message service API callback
Control Message: When there is an event of VMM, it transmits a control message to all loaded VXD programs in the system. Control messages are like a message for a third level of Windows applications. Each VXD program has a function of accepting and processing a control message called device control functions. System control messages have a total of more than 50. There are not many control messages that are usually loaded with a lot of VXD programs in the system, while each VXD program is processed when receiving a control message. If there is too much control message, it will cause the system to stagnate. So the control message only includes important messages related to the virtual machine, such as: a virtual machine is created, destroyed, and so on. As an additional to the system control message, a VXD program can define its own control messages, which can be used to communicate with those VXD programs that can respond to these messages.
Service function: A VXD program, including VMM, usually export a wide range of public functions called by other VXD programs, which are called VXD services. The mechanism to call these services and the applications running on the third level have a big difference: VXD programs for each export VXD service must have a unique ID, you can get a such ID from Microsoft. This ID is a 16-bit number that contains a unique authentication of VXD, for example:
Undefined_device_id equ 00000h
VMM_DEVICE_ID EQU 00001H
Debug_device_id equ 00002H
Vpicd_device_id equ 00003h
VDMAD_DEVICE_ID EQU 00004H
VTD_DEVICE_ID EQU 00005H
You can see the ID of the VMM is 1, the vpic ID is 3, and so on. VMM uses these IDs to find VXD programs that export required VXD services. When a VXD program exports the VXD service, it puts the address of all services in a table. So, you also need to find the service you want through the index of the service in the service branch table. For example, if you want to call the first service, getVersion service, you want to specify 0 (this index starts from 0). The real mechanism to call the VXD service includes interrupting 20h, your code produces an interrupt 20h, with a double word value, this value contains the device ID and service index. For example, if you want to call a VXD service exported by a VXD program, assume that the VXD program device ID is 000DH, the service number is 1, then the code should be:
INT 20H
DD 000D0001H
The high character following the double word after the interrupt is connected to the device ID. The low word is an index in the service list.
When executed 20H is executed, the VMM gets control and immediately detects the two words followed. Then it proposes the device ID to find the VXD program, and use the service index to locate the address of the required service in that VXD program.
You can see this time. VMM must waste a lot of time to locate the VXD program and the address of the service, so VMM made a small disadvantage. When the interrupt is successfully operation, the VMM grabs the link. That is to say, VMM uses a direct service call to replace 20h interrupt and its double word behind it. So the above 20h interrupt code snippet is changed to:
Call dword PTR [vxd_service_address]
This trick is successful because INT 20H DWORD adds a double word with 6 bytes, just equal to the Call DWORD PTR structure. So the next service call is fast and effective. This method has direct properties, simple. On the one hand, it reduces the workload of the VMM and VXD loaders because they don't have to locate all services in VXD, and those who have not performed will remain as they will. Not so good, once a service exported by a static VXD program is called, it is impossible to uninstall this static VXD program. Since the VMM locks the call to the actual address of the VXD service, if the VXD program for this service is uninstalled from the memory, other VXD programs will quickly cause the system to crash because the invalid memory address is called. There is no way to eliminate the crawled link. The conclusion of this problem is that dynamic VXD is not suitable as a service provider. Callback: The callback or callback function is a function called other VXD programs in the VXD program. Do not confuse the callback function and VXD service. The callback function is unlike services, they are private functions, and VXD gives their address to other VXD programs in a particular situation. For example, when a VXD program is processed a hardware interrupt, this VXD program cannot use the VXD service due to the VMM, otherwise the page error (re-entry VMM) is caused. This VXD program can give the address of its own callback function to VMM, so that VMM can call this function when it can endure the page error. The idea of the callback function is not a vxd. Many Windows API are in use. The best example may be a window function, you put the address of the window function in the WindClass or WindClassex structure and call it as a function to call RegisterClass or RegisterClassex. When there is a message with this window, Windows calls your window function. Another example is the window takeover function. Your program gives the address of the tube function to Windows, so when you are interested in the incident, Windows calls your tube function. The above three methods are communication between VXD, and we must also talk to the V86, protected mode, and the interface of Win32 applications. In the next chapter, we have to learn the interface of VXD to Win32 applications.
