|This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Device driver code runs with user-level access. With one exception, driver code can call Microsoft Win32 APIs and access any resources available to user-level processes. For the most part, though, device drivers need only a limited number of simple APIs. Drivers do occasionally perform more complex tasks, such as creating threads or windows. For example, on many Windows CE–based platforms, the battery driver presents a dialog box to users when the batteries drop below a threshold voltage on order to notify users to replace the batteries.
The only time that a driver cannot call Win32 APIs is when the driver processes a notification that the Windows CE-based platform is powering off or on. With one exception, the device driver must not perform any system calls while processing these notifications. To avoid these problems, restrict the device driver to the following actions when processing power off or power on notifications:
During power-on notification, the driver may call the SetInterruptEventfunction to generate an artificial interrupt event. A typical scenario is for the power on routine to set a global flag representing a power on event, and call SetInterruptEvent. Once the power on sequence is complete, the IST would be triggered by the artificial interrupt, and would then detect the global flag and performs any power on processing that requires system calls. For examples of using SetInterruptEvent, see the HWPowerOnand HWGetIntrTypefunctions in the P2io.c file.
Last updated on Tuesday, July 13, 2004