本篇文章是一篇关于applicationstate的帖子
Power Manager, included with Windows Embedded Compact 7, provides sophisticated power management support for your hardware platform. You can use Power Manager to extend battery life and improve the overall power efficiency of your system. Because Power Manager acts as a mediator between device drivers, applications, and the kernel/OEM Adaptation Layer (OAL), you can configure Power Manager to intelligently manage hardware in a way that cooperates with the needs of applications that use devices on your platform. For example, you may have an application that needs to continually update a display device while the remaining platform hardware is running in a lower power-saving mode, or your platform may allow a network device to stay powered on while the rest of platform is powered off.
 Note: |
|---|
| The term device in this context means a peripheral on a Windows Embedded Compact-based system, like a display screen or a network adapter. The term platform refers to the entire Windows Embedded Compact system: CPU, memory, and all peripherals. |
The following figure illustrates the architecture of power management in Windows Embedded Compact 7.
As shown in this figure, Power Manager communicates with applications through an application interface and a notification message queue. Applications use the application interface to request system power state transitions. For example, an application can issue a request to transition the system to a suspended state on behalf of user input. For more about the application interface, see Power Management Application Interface. Power Manager uses the notification message queue to notify applications about power-related events. For example, Power Manager informs interested applications when the OS resumes from a suspended state. For more about the notification message queue, see Power Management Notification Interface.
When Power Manager communicates with device drivers, it does so through a device driver interface and by issuing I/O control (IOCTL) commands to device drivers. Power Manager uses the DeviceIoControl function to issue IOCTLs directly to device drivers. For example, Power Manager uses IOCTLs to determine device capabilities and to update a device's power state. Because IOCTLs run in a thread context, driver developers have much more flexibility in how they implement power state change functionality. Using IOCTLs to manage power also facilitates the separation of device power state from overall system power state. Thus, some devices can be turned off while the OS is running, and others can be left on while most of the OS is suspended. Device drivers communicate with Power Manager by making calls through the device driver interface. For example, device drivers call the Power Manager DevicePowerNotify function to request device power state changes. For more about the device driver interface, see Power Management Device Driver Interface.
Power Manager observes the following rules when mediating between devices, applications, and the OS:
- System power states impose maximum power consumption limits on all devices.
- Applications impose minimum power limits on specific devices to obtain minimum performance levels.
- Power Manager permits devices to intelligently manage their own power as long as their power levels are between the minimum and maximum limits.
- If an application requests a minimum power consumption limit that is higher than the maximum power limit of the current system power state, the power level of the device that the application uses remains elevated for as long as the application requires use of the device.
- If the OS transitions to a suspended state, Power Manager ignores application-imposed minimum power limits while the OS is in the suspended state.
Power Manager maps system power states that you define for your platform to Windows Embedded Compact device power states. System power states define the overall power usage modes of your platform. These states have names such as On, Suspend, and UserIdle, and each state represents a specific power consumption profile for the devices on your platform. You can define any number of system power states for your platform, and you can specify how your platform transitions between these states. The transitions between these states can occur in any way that makes the most sense for your platform; these transitions can occur as a result of an event such as docking or undocking from a cradle or moving from AC power to battery power. You can use Power Manager to manage device power states separately from system power states so that devices that are capable of intelligently managing their own power are able to do so. For more information about mapping device power states to system power states on your platform, see Implement System Power States.
Power Manager works with devices that support one or more device power states. There are a limited number of device power states, and each device must inform Power Manager of its power consumption characteristics. Device power states generally trade performance for reduced power consumption. Power Manager does not impose absolute restrictions on device power consumption, responsiveness, or capabilities in any particular power state. Also, Power Manager generally does not request that a device go into a power state that it does not support.
Some applications may require that a device be maintained at a certain device power level. For example, a streaming audio application might require that a network card and audio codec stay powered at a high level while music is playing. A streaming video application might need access to network and audio hardware, and it might want to keep the display backlight powered on and prevent the display from going into a lower-power screen-saver mode. Applications can request that Power Manager set minimum device power-state requirements by calling the SetPowerRequirement and ReleasePowerRequirement functions. For more about how applications use these functions, see Power Management Application Interface.
Power Manager can coexist with device drivers and applications that are not developed to work with Power Manager. Within the power management framework, you define system power states that establish maximum device power states. Within these limits, device drivers can call DevicePowerNotify to regulate their own power levels, and applications can call SetPowerRequirement to verify that the devices they need are running at an acceptable device power level to meet the performance criteria of the application.
Power Manager is packaged as a dynamic link library, Pm.dll. The header file Pm.h contains Power Manager definitions such as power state flags, device class GUIDs, and power I/O control (IOCTL) definitions. You can view Pm.h at the following location:
%_WINCEROOT%\Public\Common\Sdk\Inc\Pm.h
Power Manager consists of two layers:
- Model Device Driver (MDD) layer
- Platform Dependent Driver (PDD) layer
You must modify the PDD layer to adapt Power Manager to your platform (as described in Implement System Power States), but you can also modify the MDD layer if necessary. Although Power Manager interfaces and activity timers are implemented in the MDD layer, you will find it useful to understand how they work so you can debug and test system power states in your PDD layer.
Power Manager MDD and PDD Layers
The Power Manager model device driver (MDD) layer implements the platform-independent functionality of Power Manager, such as maintaining lists of device drivers and applications and servicing the API functions that are used for communications between Power Manager, applications, and device drivers. The Power Manager MDD source code is available at the following location:
%_WINCEROOT%\Public\Common\Oak\Drivers\Pm\Mdd
The build system uses this source code to generate the library Pm_mdd_lib.lib; it links this library into the Power Manager dynamic link library, Pm.dll.
The Power Manager platform dependent driver (PDD) layer is responsible for deciding when and how to manage system power state transitions. It monitors the platform's system power states and events (such as a "low battery" event) to determine what the next system power state should be. The PDD layer notifies device drivers and applications of system power state changes through data structures maintained in the MDD. The PDD layer is also responsible for changing device power states when the MDD calls it to do so.
The PDD layer source code is separated into common code and platform-specific code. The common code provides the following functionality:
- Creates message queues for receiving notifications from applications and device drivers.
- Initializes variables used to update the platform's power status.
- Refreshes Power Manager's power source and power level variables.
- Reads messages from the notification queue.
- Sends battery notifications and reacts to power button press and release notifications.
The Power Manager PDD layer common code is available in the following location:
%_WINCEROOT%\Public\Common\Oak\Drivers\Pm\Pdd\Common
The build system uses this source code to generate the library Pm_pdd_common_lib.lib; it links this library into the Power Manager dynamic link library, Pm.dll.
The Power Manager PDD layer platform-specific code implements Platform Manager functionality that is unique to your hardware and your system power state definitions. This code resides in your platform directory at the following location:
%_WINCEROOT%\Platform\<your platform>\Src\Drivers\Pm\Pdd
The build system compiles the code in this location and links it with Pm_mdd_lib.lib and Pm_pdd_common_lib.lib to create the Power Manager library for your platform, Pm.dll.
For information about integrating Platform Manager sample PDD source code into your platform directory, see Implement System Power States.
Power Manager supports three interfaces: a notification interface, an application interface, and a device driver interface. Each interface is intended for a particular type of client, as listed in the following table.
Power Manager Interfaces
| Interface | Client Type |
|---|---|
|
Notification |
Applications that request notification of power events. |
|
Application |
Applications that request a new system power state or impose device performance requirements. |
|
Device Driver |
Power Manager-aware device drivers. |
Power Management Notification Interface (Windows Embedded Compact 7)
Notification Functions
| Function | Description |
|---|---|
|
Requests that Power Manager send notifications of system power events. |
|
|
Cancels a notification request made by RequestPowerNotifications. |
Power Manager delivers notifications through message queues. To receive notifications, an application must create a message queue and pass the message queue handle to Power Manager by calling the RequestPowerNotifications function. Applications typically create a thread that waits for notifications from the message queue. Power Manager supports the notifications shown in the following table. An application developer can specify one or more of these notification flags to indicate which notifications his application is to receive.
Notification Types
| Notification | Description |
|---|---|
|
PBT_RESUME |
Generates notifications when the system resumes from a suspended state. |
|
PBT_POWERSTATUSCHANGE |
Generates notifications when the system transitions to or from AC power. |
|
PBT_TRANSITION |
Generates notifications when Power Manager is performing a system power state change. |
|
PBT_POWERINFOCHANGE |
Generates notifications when battery information or AC line status changes. |
|
PBT_SUSPENDKEYPRESSED |
Generates notifications when the user has pressed the suspend key. |
Applications can specify the bit mask POWER_NOTIFY_ALL to indicate that the application needs to receive every type of power notification.
Power Management Application Interface (Windows Embedded Compact 7)
Power Manager provides several functions to allow applications to affect system and device power management. Of the functions in this list, only GetSystemPowerState, SetPowerRequirement, and ReleasePowerRequirement are intended for use by typical applications. The remaining functions, SetSystemPowerState, GetDevicePower, and SetDevicePower, are intended for use by OEM applications such as Control Panel utilities. For example, because SetDevicePower does not implement a reference counting mechanism, it cannot be called by multiple applications.
The following table lists the power management functions of the application interface.
Application Interface Functions
| Function | Description |
|---|---|
|
SetPowerRequirement |
Requests that Power Manager maintain the power state of a device at a minimum level. |
|
ReleasePowerRequirement |
Informs Power Manager that it no longer needs to maintain the device minimum power state set in a previous call to SetPowerRequirement. |
|
GetSystemPowerState |
Returns the name of the current system power state. |
|
SetSystemPowerState |
Requests that Power Manager change the current system power state. |
|
GetDevicePower |
Returns the current power state of a device. |
|
SetDevicePower |
Requests that Power Manager change the power state of a device. |
Applications call SetPowerRequirement and ReleasePowerRequirement to request device power levels. In some situations, applications may want to influence how Power Manager administers system power states. For example:
- A pager application might want to keep device COM3: at device power state D3 or higher while the rest of the system is in a suspended state so that an incoming page can wake the system
- A streaming audio application might want to keep the network card and audio system at full power even when the system is on battery power and has been idle for a while.
To handle these situations, Power Manager provides the SetPowerRequirement function to support applications that have special power management needs. Applications can call SetPowerRequirement to request that Power Manager set a minimum power requirement on device power states. If an application sets a power requirement, Power Manager does not allow devices to set their own power state below that specified by the requirement. When Power Manager transitions the platform to a new system power state, it typically keeps this device requirement in force, even if doing so maintains the device at a higher power level than specified for the new system power state.
Power Manager normally ignores device power requirements when the OS is in a suspended state. When the OS is in a suspended state, the CPU is stopped and the OS does not service interrupts. A device driver must disable itself if the OS is suspended. Power Manager can ignore device power requirements under other circumstances, as well. For example, you may choose to interpret the POWER_STATE_CRITICAL flag as indicating that the battery level of the OS is critically low and that all devices should be turned off. Modifying the interpretation of power state flags (also referred to as hints, as explained below) is described in Implement System Power States.
Applications call GetSystemPowerState and SetSystemPowerState to influence system power state transitions. Although you may want the application to directly change the system power state by calling SetSystemPowerState, applications cannot know which power states are available on a given Windows Embedded Compact-based platform, nor can they know the characteristics of the system power states that are available. Rather than call the SetSystemPowerState function with an explicit state name, you can design your application to invoke SetSystemPowerState with a power state bit mask describing the characteristics of the power state into which the system should transition. Each power state bit is referred to as a hint because it doesn't necessarily map directly to a system power state. Some hints can map to multiple system power states. For example, an application might request a system power state change by setting the POWER_STATE_SUSPEND hint flag. On a platform that supports Suspended and SuspendedCradle system power states, Power Manager could use this hint to transition into either state, depending on whether the device is in a cradle at the time of the request. If the device is removed from the cradle while in the SuspendCradle state, Power Manager transitions into the Suspended state.
The following table lists predefined power state hints and their suggested interpretations.
Power State Hints
| Hint | Description |
|---|---|
|
POWER_STATE_ON |
The highest functional level and highest power consumption mode of the platform. Devices are powered on and the platform is operating at a normal performance level. |
|
POWER_STATE_OFF |
All devices are powered off. Resuming from this state results in a cold boot. |
|
POWER_STATE_CRITICAL |
The battery is critically low. The OS carries out required system maintenance, turns off power to devices, and puts dynamic random-access memory (DRAM) into a self-refresh state. Resuming from this state results in a cold boot. |
|
POWER_STATE_BOOT |
The system is in the process of booting. |
|
POWER_STATE_IDLE |
No devices are in use, and there is no user interaction. Devices enter a low-power state and the platform enters a low-power mode. You can use this state as an alternative to suspending the system if the power saved from the low-power mode is satisfactory. |
|
POWER_STATE_RESET |
Flushes files, shuts down devices, and issues the IOCTL_HAL_REBOOT command to the kernel. |
|
POWER_STATE_SUSPEND |
The OS is suspended and Power Manager ultimately calls a PowerOff function. |
These power state hints are defined in Pm.h. The Power Manager sample PDD implementation does not use all of the power state hints listed in this table. You can define new power state hints that are specific to your platform, and you can modify Power Manager so that it interprets power state hints differently for the system power states defined for your platform. For more about modifying Power Manager system power state functionality, see Implement System Power States.
When an application requests a new power state by calling SetSystemPowerState with one or more power state hints, Power Manager does the following:
- Broadcasts a PBT_TRANSITION notification on the notification message queue.
- Updates the device power state, if necessary, for all device drivers. If a device is already at an acceptable power state for the new system power state, Power Manager will not issue an IOCTL_POWER_SET command to the device driver for that device.
- If the system is resuming from a suspended state, Power Manager broadcasts a PBT_RESUME notification on the notification message queue.
For more about Power Manager application interface functions and power state hints, see Windows Embedded Compact 7 documentation.
Power Management Device Driver Interface (Windows Embedded Compact 7)
Power Manager-aware device drivers use the following functions to request service from Power Manager.
Device Driver Functions
| Function | Description |
|---|---|
|
Used by device drivers to request Power Manager to update their device power states. |
|
|
Used by bus drivers and other proxy power managers to intercept all power IOCTLs for a device. |
|
|
Terminates the proxy relationship initiated by a call to RegisterPowerRelationship. |
|
|
Notifies Power Manager of the events required for implementing a power policy. |
Typically, device drivers call the Power Manager DevicePowerNotify function to request device power state changes. Keyboard, keypad, and battery drivers typically call the PowerPolicyNotify function to notify Power Manager of events through message flags. For example, a keypad driver sends the PPN_POWERBUTTONPRESSED message to notify Power Manager when the power button is pressed.
Power Manager issues IOCTL commands to power-managed device drivers through the DeviceIoControl function. Power Manager uses the following IOCTLs:
Power Management IOCTLs
| IOCTL | Description |
|---|---|
|
Requests that the device driver inform Power Manager of which power states it supports and the characteristics of those states. |
|
|
Requests that the device driver update its device power state. |
|
|
Asks the device driver if it is ready to put the device into a new device power state. |
|
|
Requests that the device driver inform Power Manager of its current device power state. |
|
|
Notifies the driver of the parent device to register all devices it controls. |
Note that, because Power Manager uses a single thread to issue IOCTL_POWER_SET commands to device drivers, device drivers must implement IOCTL_POWER_SET as a non-blocking command. If a device driver blocks during an IOCTL_POWER_SET operation, it can delay Power Manager from completing system power state transitions in a timely fashion, depending on how long it takes for the device driver to complete the IOCTL_POWER_SET command. These delays may be unacceptable when powering off or transitioning to a Suspended state, depending on the requirements of your platform hardware. For more information about these functions and IOCTLs, see Windows Embedded Compact 7 documentation.
Because Power Manager uses DeviceIoControl to communicate with device drivers, power-managed drivers must expose a stream interface. For more about device driver architecture and device driver stream interfaces, see Planning Your Device Driver. For more about how device drivers support power management, see Implementing Your Device Driver.
When you configure system power states for your platform, you can specify a device power state for each device in your platform. In some cases, you may have multiple versions of the same platform where each platform uses the same set of system power states, but each platform has a different set of devices. To simplify system power state definitions across these platforms, you can specify devices by using device class GUIDs instead of exact device names. For example, you can specify that a particular system power state places all block devices in device power state D4, regardless of the actual block device that is in use on that platform. To do this, you use the block device class GUID instead of an actual block device name.
Windows Embedded Compact 7 defines the following Power Manager device class GUIDs.
Power Manager Device Class GUIDs
| Device Class | GUID |
|---|---|
|
Generic Devices |
|
|
Block Devices |
|
|
NDIS Miniport Devices |
|
|
Display Devices |
|
|
Touch Devices |
|
|
Backlight |
|
Applications obtain a list of power-managed classes by enumerating the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\Interfaces
If an application calls a Power Manager function without qualifying the device with a class, Power Manager assumes that the device belongs to the generic power-managed device class. To understand how you can use these class GUIDs to specify device power states for particular classes of devices, see Implement System Power States.
You can use Power Manager device class GUIDs to create class-qualified device names. Class-qualified device names are device names for power-manageable devices. A class-qualified device name is a device name that is prefixed with the class GUID rendered as a string, followed by a backslash (\). For example, {8DD679CE-8AB4-43c8-A14A-EA4963FAA715}\DSK1: refers to a power-managed block device named DSK1. For more information about device naming conventions, see Planning Your Device Driver.
文章结束给大家分享下程序员的一些笑话语录： PC软件体积大，是因为一个PC软件功能往往较多，能够满足你一个方面的需求，而一个iphone软件往往没几行代码，干一件很小的事情，自然需要的软件就多。就像吃西瓜和吃瓜子的来比数目，单位不同啊。
---------------------------------
原创文章 By
application和state
---------------------------------