Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about the dynamic loading of Windows CE dirty drivers. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

I think many WinCE developers, especially those who are new to driver development, have encountered such a problem: to write a peripheral driver, for example, the simplest GPIO driver, it may only take a while to write the driver itself, but to package the compiled DLL into a previously done operating system image, it is easiest to MakeImg and modify the BIB file and registry file. So that the driver will be loaded when the system starts, all the work is done, and it will take a few minutes to download the entire operating system into memory to run, which will also take several minutes. A person with strong ability succeeds once, even if he doesn't turn back.

If there's something wrong with the driver, you'll have to change the code, recompile, and do what you just did. Say it is not afraid of everyone's joke, I just started to do the driver like this, over and over again, half a day down, just debug a simple driver. In fact, a large part of the time is wasted on repetition. This debug-driven method is too inefficient. How convenient it is to think of the driver debugging under Linux! INSMOD directly, the application can be called, if there is a problem, RMMOD, there is no need to toss the operating system image file back and forth. So, isn't there such an easy way to do it under WinCE? The answer is yes.

Cut the gossip and get to the point. Find the help of EVC and find that the function ActivateDevice () can be used to load the driver. The use of this function is quite simple. I won't say any more. Posting a paragraph of help is the most illustrative. Of course, you can also use ActivateDeviceEx ().

HANDLE ActivateDevice (

LPCWSTR lpszDevKey

DWORD dwClientInfo

);

Parameters

LpszDevKey

[in] Pointer to the registry path string of the device's driver key under HKEY_LOCAL_MACHINE. A driver key contains the DLL name, the device prefix, friendly name, and other device information.

DwClientInfo

[in] Data that will be stored in the device's Active key in the ClientInfo value. The registry path to the driver's Active key is passed in as the context parameter to the device's XXX_Init function. The value in dwClientInfo is stored in the registry before XXX_Init is called.

Return Values

On success, ActivateDevice returns a handle to the device that can be used in subsequent calls to DeactivateDevice.

Remarks

This function is superseded by ActivateDeviceEx.

ActivateDevice loads a device driver. ActivateDevice reads the registry key specified in lpszDevKey to get the DLL name, device prefix, index, and other values. Next it adds the device to the active device list in the registry branch HKEY_LOCAL_MACHINE\ Drivers\ Active, and stores the relevant values there. If no device index was specified in the key named in lpszDevKey, then it assigns a free index. Then it loads the device driver DLL in the process space of the Device Manager. Then it broadcasts a WM_DEVICECHANGE message for the new device and triggers a NOTIFICATION_EVENT_DEVICE_CHANGE event in the application notification system to notify applications of the presence of the new device.

As you can see from the above description, when using this function, we only need to give the first parameter, which is a path string in the registry. Therefore, in order to easily dynamically load any driver, we also need to know about the registry. But one of the core is a, you drive the relevant registry information into the HKEY_LOCAL_MACHINE, including Prefix, DLL, Index, Order and other information. I won't explain it here.

It was really depressing that I spent so much unjust time at first. After figuring out the principle, I made a small tool to realize the dynamic load stream driver, in order to improve the development efficiency and facilitate the later generations. The following is a detailed description of the use of this gadget, so that you can experience how enjoyable it is to dynamically load stream drivers.

We assume that we have made a simple stream-driven DrvDemo.dll with the corresponding registry file DrvDemo.reg, which is used to test the driven application DrvDemo.exe. We copy these three files and the driver debugging assistant (DM.exe) to the WinCE system, as shown in the following figure.

First run DrvDemo.exe, click on the device, or other buttons, we find that the device failed, it is normal, at this time DrvDemo.dll is not working yet.

Run the driver debugging assistant software DM.exe, click the "driver debugging" menu-select "Import Registry"

Or activate from the driver list.

The rest of the operation is exactly the same as mentioned above and will not be repeated.

Well, this method is very similar to Insmod and Rmmod under Linux, right?

In fact, if you already have the corresponding key in the registry, you can even select it directly, and then select "activate driver" in "driver debugging". If everything is all right, you can achieve the effect of the above two methods. but it saves even importing files. Comrades who are interested can try it for themselves.

Well, I believe that at this point, you should understand the principles and methods of dynamically loading stream drivers, and you can get rid of the nightmare of constant MakeImg and Download and save a lot of valuable development time.

Finally, the driver debugging assistant briefly explains a few points to pay attention to.

1. When debugging a driver, after loading the driver, do not turn off the driver debugging assistant and minimize it, otherwise, it will automatically unload the driver you loaded when it is turned off.

two。 In WinCE4.2, drivers related to interrupts cannot be loaded dynamically by this method directly, and there is no such restriction in 5.0,6.0. This is due to the interrupt handling mechanism in WinCE4.2.

3. Driver debugging assistant can load several drivers at the same time, it is recommended to write all the registry information to one file and import it. All that's left is to choose from the list of drivers to load the drivers you need.

4. The registry editing function in the driver debugging assistant has been basically improved after several modifications, and there is no problem with editing, importing and exporting. If the system supports HIVE-REG, you can choose to save this registry change when you exit the driver debugging assistant.

5. The screenshot above is done on the simulator of WinCE6.0, which should be regarded as the driver in kernel mode, and the driver in user mode can also be loaded by this method, but the corresponding registry information needs to be set.

This is what the dynamic loading of the Windows CE downstream driver shared by the editor is like. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.