Wince driver category

[Author: We-hjb]

[Link:] http://www.cnblogs.com/we-hjb/archive/2008/11/23/1339603.html

 

Recently, some people sent an email asking me which drivers can be dynamically loaded by the driver debugging assistant and why it always fails when loading the driver of the USB device. To solve this problem, you must first understand the driver concepts in wince. This article mainly introduces the driver categories under wince.

A driver is a code layer between an operating system and a device. Its main function is to provide an interface for the operating system to operate on different hardware, including physical and virtual devices. Although there are many types of drivers, from the programming point of view, it is nothing more than adding the corresponding code to a fixed framework. The framework here refers to an interface for the operating system. The purpose of code implementation is to write the correct value to the correct register at the right time.

Driver classification, which varies from different perspectives. Take the serial driver for example, you can say that it is a hierarchical driver, you can also say that it is a stream driver, you can also say that it is a driver automatically loaded when the boot ...... This seems a bit messy. If you think so too, we recommend that you look down. If you know all this, it will not be a waste of time. Of course, you are willing to find something, I will thank you very much!

Let's talk about native drivers and stream drivers ). Drivers under wince can be classified into these two categories. This is distinguished by the interfaces provided by the driver to the operating system. The stream Driver provides stream interface functions for the operating system, such as xxx_init (), xxx_open (), xxx_read (), xxx_write (), and xxx_close. This type of driver is managed by Device Manager, which calls the ActivateDeviceEx () function to load the stream driver. The ActivateDeviceEx () parameter is the corresponding key in the registry, used to set the attributes of the stream driver, such as index, order, and prefix. The stream-driven registry configuration information is generally stored in [HKEY_LOCAL_MACHINE/Drivers/builtin. After the stream driver is loaded successfully, the application calls createfile (), readfile (), and wirtefile () to access the device of the stream driver. The stream driver can be dynamically managed, and the driver debugging assistant is used to help debug such drivers.

In contrast to the stream driver, what the local driver provides to the operating system is not a standard stream interface, but a specific interface agreed in advance. Different devices have different interfaces. In wince, common local drivers include LCD driver, touch screen driver, mouse and keyboard driver, and printer driver. We can see that the local driver is mainly related to the man-machine interface. They are managed by GWES and loaded at system startup. They also have their own configuration information in the registry. For example, the Registry configuration of mouse and keyboard is as follows:

[HKEY_LOCAL_MACHINE "system" CurrentControlSet "control" layouts "00000409]

"Layout file" = "kbdmouse. dll"

"Layout text" = "us"

"Ps2_at" = "kbdmouse. dll"

"Matrix" = "kbdmouse. dll"

The local driver is called by the operating system and cannot be accessed by applications. For such drivers, the driver debugging assistant is powerless and can only be honestly compiled, downloaded, and verified.

Model Device Driver and PDD (platform dependent driver) are often heard in the wince driver, which are distinguished by the structure of the driver code implementation. The driver of Wince can be single-layer or PDD + mdd. There is no rigid rule that a driver can adopt a layered structure or a single layer structure. In general, the driver execution efficiency of a single-layer structure is higher, while the driver of a hierarchical structure facilitates code maintenance and transplantation. Taking the serial driver as an example, a single-layer structure can be used. It is divided into PDD and mdd. As a general developer, we only need to implement the PDD layer, and the MDD layer is implemented by Microsoft. In this way, the workload for development is much less, and the code reliability is better guaranteed. What kind of structure is used as the driver depends on your needs.

Wince 6.0 introduces the concepts of kernel-mode drivers and user-mode drivers. In wince5.0 and earlier versions, the driver works in user mode. From the code perspective, there is no big difference between kernel-mode drivers and user-mode drivers. If no special technology is used in the driver, the kernel-mode driver is Binary compatible with the user-mode driver. I have tried to load a DLL to the kernel state and user State, both of which work well. The kernel-state driver is loaded into the kernel space, and the user-state driver is loaded into a specific user process space. In terms of execution efficiency, the kernel-mode driver is more efficient than the user-mode driver. In terms of stability, user-mode drivers do not have a fatal impact on the system, while kernel-mode drivers are relatively dangerous. Which type of driver is also your requirement.

The driver loading time can be divided into two types: loading at system startup and loading when needed. Generally, local drivers are loaded at startup, so here we mainly talk about stream drivers. To load a driver when the system starts, you only need to put its registry configuration information under [HKEY_LOCAL_MACHINE/Drivers/builtin/], for example, [HKEY_LOCAL_MACHINE/Drivers/builtin/battery]. when the system starts, Device Manager Automatically loads it. Load when needed. As the name suggests, it is flexible to load when you want to load and unload. It is necessary to talk about the driver loading of the USB device, such as the USB camera driver, which also belongs to the driver that needs to be loaded. From the perspective of the driver interface, it is a stream driver, but it is relatively common, it adds several functions: USB deviceattach (), USB installdriver (), USB uninstalldriver () and so on. The USB camera driver is loaded in USB deviceattach. Therefore, it does not need or cannot be loaded by the driver debugging assistant. The driver that needs to be loaded has another function. When the system cannot be modified, the driver is dynamically loaded in the application to complete hardware operations.

To sum up, the wince driver classification mainly includes the following methods:

Driver interfaces can be divided into local drivers and stream drivers;

Based on the driving structure, it can be divided into single-layer drivers and stratified drivers;

The space loaded by driver can be divided into kernel-mode drivers and user-mode drivers;

By driver loading time, it can be divided into loading at startup and loading at need.

The driver debugging assistant is used to dynamically manage the stream driver. The local driver and USB driver are no longer under its control. Please pay attention to this when using them.

If there are any mistakes in this article, please leave a message to correct them. If you have any questions, please leave a message for discussion.