Common methods for Windows hardware notification applications (Five ways: Asynchronous procedure call APC, event mode VXD, message mode, asynchronous I/O mode, Event mode WDM)

Abstract: In today's popular Windows operating system, device drivers are the lowest-level software interface for manipulating hardware. In order to share the experience in the process of device driver programming, 5 Methods of notification application of device driver are given, and the principle and implementation process of each method are described in detail, and some core code of implementation is given. Want to be able to provide some help to the designer of the device driver.

Keywords: Device driver asynchronous I/O Virtual device Driver (VxD) Windows Driver Model (WDM)


Introduction
In a DOS operating system, applications can deal directly with hardware, including I/O port reads and writes, interrupt requests and responses, and DMA operations [1]. This kind of hardware is too direct to the software design to provide some convenience, but there are some of its own shortcomings. First, some illegal operations may overwrite the contents of certain hardware registers, causing the operating system to crash, making the operating system unsafe and performance unstable; second, the portability of the application becomes worse. To ensure the security and stability of the operating system and the portability of the application, the Windows operating system does not allow applications to directly access the system's hardware resources, but must rely on the appropriate device drivers. The device driver can operate the hardware directly, and if two-way communication between the application and the device driver is achieved, the application controls the underlying hardware device. The communication between them consists of two aspects: one is the data that the application transmits to the device driver, and the other is the message that the device driver sends to the application. The former is easier to implement, and after acquiring a handle to the device driver through the CreateFile () function, you can use the WIN32 function, such as DeviceIoControl (), ReadFile (), or WriteFile () [2] to implement communication between the application and the device driver. DDK and MSDN have a detailed description of them, and the reader can refer to the relevant information. The latter's implementation is far more complex than the former, while the articles on this aspect are less. This does not mean that it is unimportant, instead it plays an important role in some applications. For example, in a data acquisition system, when an application sends a command to a device driver to collect data, a worker thread is created to wait for the data collection to complete, and the application itself can continue to do other work. After the device driver completes the data acquisition, it needs to notify the application immediately so that the application can take the data and process it in a timely manner. Things like that.

In view of the importance of the device driver notifying the application, the author summarizes it with some experience and available information, and concludes 5 methods: Asynchronous procedure Call (APC), event mode (VxD), message mode, asynchronous I/O mode, and event mode (WDM). The following describes the principle of these methods, and gives the implementation of some of the source code.

1 Asynchronous procedure Call (APC)

The WIN32 application uses the CreateFile () function to dynamically load the device driver, then defines a callback function Backfunc (), and takes the address of the callback function &backfunc () as a parameter, through the DeviceIoControl () Transmitted to the device driver. After the device driver obtains the address of the callback function, it saves it in a global variable (such as callback) and calls the Get_cur_thread_handle () function to get its handle to the application thread. and save the handle in a global variable (such as Appthread). When the condition is ripe, the device driver calls the _VWIN32_QUEUEUSERAPC () function to send a message to the WIN32 application. This function takes three parameters: the first parameter is the address of the callback function (already registered), the second argument is the message passed to the callback function, and the third parameter is the caller's line Cheng (already registered). After the WIN32 application receives the message, it automatically calls the callback function (actually called by the device driver). The input parameters of the callback function are filled in by the device driver, where the callback function is primarily handling the message.

2 event Mode (VxD)

First, the WIN32 application creates a handle to an event, which is called a Ring3 handle. Because the virtual device driver uses the RING0 handle of the event, you need to create a RING0 handle. Use the LoadLibrary () function to load the non-exposed dynamic-link library Kernel32.dll to get a handle to the dynamic-link library. Then, call GetProcAddress () to find the position of the function openvxdhandle () in the dynamic-link library. Next, use the Openvxdhandle () function to convert the Ring3 event handle to the RING0 event handle. The WIN32 application loads the device driver with the CreateFile () function. If the load succeeds, the DeviceIoControl () function is called to pass the RING0 event handle to the VxD, while a worker thread is created to wait for the signal to become signaled and itself to do something else. When the condition is ripe, the VxD RING0 event is signaled (called the _vwin32_setwin32event () function), which immediately triggers the corresponding Ring3 event for the signaled state. Once the Ring3 event handle is signaled, the WIN32 application's worker thread handles the message accordingly.

3 Message Mode

The WIN32 application calls the CreateFile () function to dynamically load the virtual device driver. After the load is successful, the form handle is passed to Vxd,vxd by calling the DeviceIoControl () function to send a message to the form using this handle. When the condition is met, the VXD calls the Shell_postmessage () function to send a message to the WIN32 application. For this function to work successfully, you must define a message with a # define, and you will still have it defined in your application, and you will use On_message () in the message loop to define the message handler function for the message, so that the message handler function can be invoked when the message is generated. The first argument to the Shell_postmessage () function is the Win32 form handle, the second parameter is the message ID number, the third to fourth parameter is the argument sent to the message handler, and the fifth to sixth parameter is the callback function and the parameter passed to it. After the WIN32 application receives the message, it processes the message.

4 asynchronous I/O mode

The WIN32 application first calls the CreateFile () function to load the device driver. When the function is called, the 2nd parameter is set to file_attribute_normal| File_flag_ OVERLAPPED, which indicates that the file can be overlapped I/O later. When the device driver file is created successfully, an event with an initial state of no signal, requiring a manual reset is created, and the event is passed to a data structure of type overlapped (such as overlapped). The overlapped is then passed as a parameter to the DeviceIoControl () function. The device driver sets the I/O request package (IRP) to a pending state, and sets a cancellation routine. If the current IRP queue is empty, the IRP is routed to the Startio () routine; otherwise, it is placed in the IRP queue. After the device driver finishes this work, the DeviceIoControl () is ended, and the Win32 application may not wait for the IRP to finish processing, returning from the call to DeviceIoControl (). The processing of the IRP is obtained by judging the return value. If the current IRP is in a pending state, the main program does some other work first, and then calls the WaitForSingleObject () or waitformultipleobject () function to wait for the event in the overlapped to become signaled. The device driver handles the queued IRP when appropriate, and calls the IoCompleteRequest () function when processing is complete. This function sets the event in overlapped to a signaled state. The Win32 application responds immediately to the event, exits the wait state, resets the event to a signal-free state, and then calls the GetOverlappedResult () function to obtain the processing result of the IRP.

5 Event Mode (WDM)

The WIN32 application first creates an event, passes the event handle to the device driver, creates a worker thread, waits for the event to be signaled, and then goes on to do something else. After the device driver obtains the handle to the event, it converts it to an event pointer that can be used, and it is stored for later use. When the condition is available, the device driver sets the event to a signaled state so that the application's worker thread knows the message immediately and then handles it accordingly. When the device driver is no longer using this event, the event's pointer should be lifted.

In the Web Supplement version (http://www.dpj.com.cn) of this newspaper, some of the code implemented in each section is described.

Conclusion

In today's popular Windows operating system, device drivers are the lowest-level software interface for manipulating hardware. It provides an up-to-the-hardware-agnostic user interface for direct I/O, hardware interrupts, DMA, and memory access. It shields the application from hardware details, makes the software independent of hardware and can be ported between multiple different platforms. This article describes 5 device driver notification application methods, of which the first 3 methods are mainly used in VxD, and the last 2 methods are mainly used for WDM. These 5 methods are tested in real-world form. Test results show that they are able to achieve the purpose of the device driver notification application.

Reference documents
1 tournament Li, Xu Jianbo, Guoji, et.   Research and development of VxD for virtual device driver [J]. Computer Engineering, 2003,28 (3): 45~46
2 (US) Chris Cant.   Windows WDM Device Driver Development Guide [M].   Sun Yi, Mary, Coere and other translations.   Beijing: Mechanical Industry Press, 2000. 20~50
3 Karen Hazzan.   Windows VxD and device driver authoritative guide [M].   Sun Ximing translation.   Beijing: China Power Press, 1999. 28~100
4 Walter Oney.   Programming the Microsoft Windows Driver model[m].   (US) Microsoft Press, 1999. 35~180
5 Li Heping.   Research of ICT image reconstruction system based on DSP [D]. Beijing: College of Mechanical Engineering and automation, Beijing University of Aeronautics and Astronautics, 2002
Zhou Zhengan: Ph. D., professor, the main research direction is computer control technology and digital image processing technology. Li Heping: Master, Research direction for data acquisition and image processing. An Zhengang: Postdoctoral, research direction for electromechanical control and automation.

http://blog.csdn.net/kl222/article/details/5866769

Common methods for Windows hardware notification applications (Five ways: Asynchronous procedure call APC, event mode VXD, message mode, asynchronous I/O mode, Event mode WDM)