Device drivers are user-level processes, which means that the 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, such as memory allocators. Drivers do occasionally perform more complex tasks, including 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, thus notifying users to replace the batteries.
The only time a driver cannot call Win32 APIs is when the driver processes a notification that the device is shutting down. In this situation, the device driver must not perform any operations that might cause a context switch. For example, if the driver attempts to open a file during this time, the kernel might need to access the file system, swap pages out of memory, and use other system resources that might depend on separate execution contexts. To avoid these problems, restrict the device driver to the following actions when shutting down:
When power returns, the driver can restore the device state from the saved information.
The driver can also use the SetInterruptEvent function to generate an artificial interrupt event. By calling SetInterruptEvent, a driver can force release of the interrupt thread to continue any necessary processing. For examples of using SetInterruptEvent, see the HWPowerOn and HWGetIntrType functions in the P2io.c file. Drivers should call these functions only during suspend and resume processing.