OnNow Pow. Mgmt. Architecture for Applications
This paper demonstrates how developers of Microsoft Win32-based applications can take advantage of OnNow power management capabilities in the Microsoft Windows 98 and Windows 2000 operating systems. OnNow provides enhanced features for end users and improves system power efficiency and robustness for Internet or intranet applications, multimedia applications, and scheduling applications.
This paper also demonstrates how PC equipment manufacturers and hardware vendors can exploit their power management applications and utilities using new OnNow-capable hardware.
On This Page
OnNow Design Initiative References
Introduction
The OnNow design initiative seeks to ensure that new PCs are instantly accessible to users at the touch of a button and that all elements of the system--applications, devices, and user interface--can take advantage of the vast improvements in PC power management technology and capabilities through the operating system.
Applications play the most critical role in the user's experience with a power-managed PC. In traditional power-managed systems, the hardware and BIOS attempt to provide power management for the system in a way that's transparent to the applications.
This has resulted in some legendary user problems such as screens going blank during video or slide-show presentations, annoying delays while disks unexpectedly spin up, and low battery life because of inappropriate device usage. Applications have direct knowledge of how the user is using the PC to perform some function. This knowledge must be integrated into the power-management decision-making in the system in order to prevent these kinds of user problems.
The system architecture that supports OnNow provides a new API (application programming interface) set that makes it easy for software engineers to ensure that their applications contribute to the power efficiency and robustness of OnNow-capable PCs. The OnNow PC platform also offers new opportunities for applications to add functionality for users. Areas to be explored and mined for exciting new features in Win32-based applications include the following:
| • | Automating Internet updates or system-maintenance utilities. An Internet application can schedule times to turn on the PC so the application can download information from the Internet without user attendance. Management applications can schedule off-peak times to wake the PC to run activities such as software downloading, backup, or maintenance. Such applications can use the OnNow extension APIs to inform the operating system when activities are complete so that the PC can be immediately put back to sleep. |
| • | Handling docking changes for mobile users. Consider the following scenario: You are working on a file stored on the network or on a disk in a docking station. But you're late for a flight, so you put the PC to sleep, undock, and leave. Later, at home or in your hotel room, you turn on the PC. If the application is not OnNow-aware, it might hang or fault when it tries to access the file. By handling the sleep and wake events, the application can smoothly manage the situation by telling the user what happened and offering to save the work to another location until the original volume is available. |
| • | Preserving network connections. This scenario is similar to the docking scenario: When the PC goes to sleep, network connections on the server are lost, files are closed, and file locks are freed. An OnNow-aware application can automatically handle this by performing a local auto-save when the system goes to sleep. When the system wakes, the application can re-establish its connection and silently allow the user to continue working. |
| • | Keeping presentations online. Every presenter has seen a laptop turn off or go blank in the middle of a presentation. While a slide is being displayed, the PC perceives itself to be idle, as if the user has left it alone; no CPU is needed and no user input is coming in. An OnNow-aware application tells the operating system that the PC is being used, thus preventing the screen or PC from turning off. |
| • | Extending mobile battery life. Battery life is essential to laptops. The application's use of the CPU and hard disk drastically affects battery life. Performing non-essential background tasks in the idle loop prevents the CPU from entering a low power state. By taking advantage of OnNow capabilities, an application can find out whether the PC is running on batteries and, if so, can turn off some of the application background tasks. Further, an application can postpone low-priority disk I/O to be performed only when the hard drive is running. |
| • | Handling events for network agents and peripherals. Both network agents and applications for peripherals such as fax machines can deliver continuous functionality (24 hours per day, months at a time) without requiring the PC to run at full power to execute tasks when events occur. |
The OnNow design initiative is well under way, and the required changes in hardware, firmware, and software will soon be available as a mainstream feature on all PCs. These changes mean that power management will be a feature for all PC hardware, even add-on devices, providing an opportunity for applications to take advantage of those features and to offer new capabilities to users while improving the robustness, power efficiency, and functionality of the PC system as a whole. Because the operating system will control and coordinate power management, a unified user interface will be available, with minimal configuration demands for the user.
OnNow Call to Action for Application Developers
Following is a summary of what can be done now to design applications that take advantage of the "always on" OnNow-capable PC platform:
| • | Implement support for WM_POWERBROADCAST messages and GetSystemPowerStatus now. These capabilities are available in the Windows 95 operating system. |
| • | New APIs and messages for OnNow are provided in the Microsoft Platform SDK. Study the API extensions in the Microsoft Platform SDK for ideas about the implementation details. |
| • | Exploit new platform capabilities in task-scheduling applications, device-driven event-handling applications, and high-availability applications. |
The "Overview of the OnNow Architecture" section that follows provides a brief look at the OnNow architecture and introduces all the components affected by the OnNow initiative.
The "Overview of OnNow Power States and Power Policy" section later in this paper summarizes the power-management policy and power states for an OnNow-capable PC. It also describes the Win32 API enhancements that enable applications to participate in OnNow.
Overview of the OnNow Architecture
The OnNow approach uses power-management hardware to put the PC into a low-power sleep state instead of shutting down completely, so that the system can quickly resume working. The operating system will automatically enter the sleep state when the PC is idle and also when the user presses a button on the front of the PC to indicate that the work session is over.
While in the sleep state, the PC's processor is not executing code and no work is being accomplished for the user. However, events in the system from both hardware devices and the real-time clock can be enabled to cause the system to exit the sleep state (that is, "wake up") and quickly return to the working state.
In order to achieve the OnNow vision of the "always on" PC, changes must be made to current designs for hardware, drivers, firmware, operating system, and applications. One of the key design innovations related to the OnNow design initiative is the movement of power-management policy decisions and coordination of operations into the operating system. The Windows 98 and Windows 2000 operating systems will incorporate changes that allow the operating system to determine power and configuration information about each device in the system and how it is being used. The operating system will control the device power states in the system and share this information with the applications.
OnNow design provides a cross-platform architecture so that the same hardware and drivers are compatible with the Windows 98 and Windows 2000 operating systems. The Microsoft Win32 API extensions for OnNow will be fully supported on both platforms. The scope of OnNow is shown in Figure 1.
Figure 1--OnNow Components
OnNow requires the following changes in the PC:
| • | Enhance the core operating system functionality for power management. In the OnNow architecture, the operating system assumes the central role of coordinating power-management activities at all levels and takes responsibility for defining the power-state transitions for the system (system power policy). |
| • | Create a unified device driver model for power management and Plug and Play. This involves the creation of a single device driver model for both Windows 98 and Windows 2000 that supports per-device power management from the outset, in addition to supporting Plug and Play. The Windows Driver Model (WDM) fills this role. For information, see the WDM articles. |
| • | Implement a new system interface for power management and Plug and Play. An interface design is required that implements operating system-directed power-management policy and enables per-device power management of devices on the system board. The Advanced Configuration and Power Interface (ACPI) specification |
| • | Define bus and device power management standards for hardware. In the same way that Plug and Play standardized configuration mechanisms throughout the PC, OnNow provides comprehensive standards for power-management interfaces and state definitions. PCI, USB, and IEEE 1394 bus standards are being enhanced to provide power management control, and separate device class power management specifications are being developed to define the expected power states and behaviors of various types of devices. |
| • | Define an application architecture that integrates applications into power management. By building on existing Plug and Play mechanisms for applications, improvements can be made in the flow of control and information through the application interface. As a result, the user's environment is more smoothly integrated with the underlying PC capabilities. The Win32 API enhancements described in this paper fill this need. |
Overview of OnNow Power States and Power Policy
To a user, an OnNow-capable PC appears to be either on or off; no other conditions are apparent. However, the PC is actually capable of transitioning through a number of different power states according to the power policy defined in the operating system. The power policy is based on a standardized set of power states. There are power states defined for the overall system ("global") and for individual devices, including the CPU.
The global states are defined as follows: working (applications are executing), sleep (software is not executing, and the CPU is stopped), and off (the system has shut down and must reboot). The sleep state is the default state the PC enters when it is idle or when the user pushes the front panel button to indicate that the current work session is over. The off state is achieved by shutting down the operating system. Figure 2 provides an overview of the OnNow global power states.
Figure 2--OnNow Global Power States
The system's global power policy is owned by the operating system's user interface component (User.exe), which tracks the user's activities (including front-panel button pushes) and application execution states to decide when the system should enter the sleep state. In tracking application execution states, some activity is known implicitly by the operating system (for example, user input or server activity). Other activities are communicated to the operating system by applications using a new API.
With OnNow, the operating system will directly control the global power-state transitions. Under the global power policy, a PC system enters the sleep state consistent with the capabilities reported by the system hardware and with any required wake-up capabilities that are enabled by currently running applications. System wake up can be time-based (such as time of day) or device-based (such as modem ring or network request).
Each device in the system has its own power states, and these are independently managed by the device driver (or other policy owner) while the system is in the working state. The device's policy integrates any particular application's needs with device capabilities and other operating system information to conserve energy without adversely affecting the work that the user is doing. For example, if the communications port is not opened by an application, there is no reason for the hardware to be consuming energy, and turning it off will not adversely affect the user. When an application opens the port, the user wants to use it, so the driver must turn it back on in a way that is transparent to the user.
Also, while the system is in the working state, the operating system transitions the CPU between its defined low-power states based on CPU usage. CPU power policy is based on the current power source (battery or AC), processing needs (idle time and so on), and user preferences.
Win32 API Extensions for OnNow
The OnNow extensions to the Win32 APIs fill two roles:
| • | As mechanisms for applications, to learn from the operating system about power events and status. |
| • | As mechanisms for applications, to tell the operating system the applications' requirements in order to influence power-management policy. |
These extensions are a superset of the existing Win32 APIs and the messages from the Windows 95 operating system. Some of these APIs are already available in released versions of the Windows 95 operating system (indicated in the following discussion with daggers: ††). Other extensions are available as new functions/messages in both the Windows 98 and Windows 2000 operating systems.
This section presents a broad overview of the new APIs that provide OnNow capabilities for applications. These APIs are grouped according to whether they are used in relation to the PC system's sleep state, system wake up, or power status. The most important of these are the SetThreadExecutionState function and the WM_POWERBROADCAST message.
Functions and Messages for the Sleep State
The SetSystemPowerState and SetThreadExecutionState functions are used to put the PC to sleep and to allow applications to tell the operating system when they are busy, respectively. The WM_POWERBROADCAST message notifies applications of system state changes. The following summarizes key information about these new functions and messages.
SetThreadExecutionState
This API is implemented in Windows 98 and Windows 2000. It can be used by an application to inform the operating system that it is busy, thereby preventing the operating system from placing the PC into the sleep state while the application is running. It can also be used to keep the monitor on--for example, to ensure a persistent display for presentation applications or multimedia playback. Event-handling applications such as fax software or network agents should also call this API to let the operating system know the state of application activities so that the PC can be put back to sleep immediately after processes are complete.
BOOL SetThreadExecutionState(EXECUTION_STATE esFlags
The esFlags parameter describes the level of support that the application requires, as summarized in the following table.
| esFlags for SetThreadExecutionState | |
| esFlags | Description |
ES_SYSTEM_REQUIRED | Indicates application is performing an action not usually detected as activity by the system. |
ES_DISPLAY_REQUIRED | Indicates application is performing an action not usually detected as display device activity by the system. |
ES_CONTINUOUS | Causes requested state to remain in effect until one of the esFlags is cleared. |
Applications designers can take advantage of the SetThreadExecutionState function in the following ways:
| • | Multimedia applications should use the ES_DISPLAY_REQUIRED flag while playing back video or static images. For example, a long display of a static image with no user input might be interpreted by the operating system as an idle state, but the application can use this flag to indicate a busy state. |
| • | Event-handling applications, such as utilities for managing incoming faxes, can use the ES_SYSTEM_REQUIRED flag while handling an event, and then clear it when the event is finished so that the operating system can return the PC to the sleep state. |
Most typical productivity applications might not have a reason to use this functionality because activity is usually determined through other means, such as user input.
SetSystemPowerState
This API was implemented in Windows 95. OEM utilities for system management can use this function to start the sleep process by querying all applications about whether sleep should proceed. Alternatively, the operating system can use this function to force the system into a sleep state, bypassing any queries. Most typical applications will not need to call this API.
BOOL SetSystemPowerState(BOOL ƒSuspend, BOOL ƒForce)
| • | ƒSuspend is currently ignored under Windows 95/98 and Windows 2000 because the terminology is ill-defined. There is no distinction between Suspend and Standby in OnNow, as there was previously under APM (advanced power management) definitions. |
| • | ƒForce determines whether queries are sent to other applications. The operating system will return FALSE if not successful or if it is already in the process of putting the PC to sleep. |
WM_POWERBROADCAST
The most important aspect of implementing OnNow capabilities in an application is how the application deals with WM_POWERBROADCAST messages.
Applications are notified of power management events through the WM_POWERBROADCAST message. Developers must ensure that their applications respond to these messages in order to properly close down application activities when the system is being put into a sleep state and to recover transparently when the PC wakes up. Specifically, when a PC is in a sleep state, network connections will definitely be closed and disks in docking stations might disappear. To protect the user and the application itself from possible problems, applications must act on the WM_POWERBROADCAST messages.
When the system is going to sleep, the application should check to determine whether it has any open files. If so, the application should perform an auto-save and silently close its files, making every attempt to manage the process without user intervention. Notice that system sleep requests are generated by the user (a button was pressed or an idle time delay occurred), so the application already has the user's implicit acknowledgment that it's OK to prepare to put the system to sleep. Therefore, the application should immediately take the steps necessary to preserve the user's work in such a way as to automatically restore it upon wake up. Applications should query the user only if an uninterruptible operation is in progress.
The power policy for determining when to turn the PC off will be based on both user and application activity in the system. The operating system determines application activity by maintaining the state of applications that have called SetThreadExecutionState. If this counter reaches zero and there hasn't been any user input for a defined interval, the operating system will shut down the PC by calling SetSystemPowerState. Notice that for OnNow-capable systems, there is no equivalent to the APM STANDBY state. On such PCs, calling SetSystemPowerState with †Suspend = FALSE will simply turn off the monitor.
When the PC system wakes automatically because of an event (but not because the power button has been pressed or because of user activity), the operating system will automatically set its inactivity timer to at least 1 minute (the actual value can be configured in the registry). The inactivity timer gives applications a chance to wake and call SetThreadExecutionState. Using this process, the operating system will be able to proactively shut down the PC's power without affecting the user, based on the following conditions:
| • | If the PC wakes itself automatically, the operating system will shut down the PC as soon as the last job finishes, as indicated by an application calling SetThreadExecutionState. |
| • | If the PC wakes itself but the user begins new input while the services applications are running, the operating system will not shut down the PC when the last job finishes. |
| • | If the PC is already on and the user is present, the operating system will not shut off the PC. |
| • | If the PC is already on, no applications are busy, and the user leaves the PC for a long time, the operating system will automatically shut down the PC. |
The following sleep state notification messages are implemented in Windows 95/98 and in Windows 2000.
WM_POWERBROADCASTwParam
This message provides Query, Sleep, and Wake notifications. The Sleep message indicates whether a user interface is allowed, although it is important that the application should use a user interface only in the case of emergency.
Notice that system wake up can be due to user actions or for handling an event (AUTOMATIC).
| Sleep State Notifications Usage | |
| Notification | Application action |
PBT_APMQUERYSUSPEND†† | If an uninterruptible process is in place, fail the message. |
PBT_APMSUSPEND†† | Silently close any files. |
PBT_APMRESUMEAUTOMATIC | Do nothing; assume the user is not present. This message is sent only if the system awakened due to a scheduled or device wakeup event. Appropriate processing for the scheduled/device wakeup event should be done only by the application that requested the scheduled/device wakeup event. Other applications should do nothing. |
PBT_APMRESUMESUSPEND†† and PBT_APMRESUMECRITICAL†† | Re-open files that were closed before sleep. |
†† Also available for use in the Windows 95 operating system.
System Wake Functions
Both scheduled times and device events can be used to wake an OnNow-capable PC. Applications schedule wake up using Win32 timer objects. Applications can also enable a device event wake up by requesting it on a specific device. Some rough wake-up latencies can be specified. This section summarizes these objects and services.
Win32 Timer Objects
The OnNow-capable operating system can ensure that the PC system is in the working state at a scheduled time. To do this, applications can use timer objects to wake the PC from a low power state (assuming sufficient power is available). The operating system will track all timer objects and program the hardware with the next wake-up time when putting the system into the sleep state.
Create, Open, Set, and Cancel capabilities will be provided in "Waitable Timer" objects for use by event-handling applications or by Windows 2000 services. The following is an example:
BOOL SetWaitableTimer(HANDLE hTimer, const LARGE INTEGER *lpDueTime, LONG lPeriod, PTIMERAPCROUTINE pfnCompletionRoutine, LPVOID lpArgToCompletionRoutine, BOOL fResume)
Device (Event) Wake-Up Functions
Any device can be a wake-up source, whether it is a modem signaling an incoming call or a more traditional input device signaling user input. The device event wake-up functions for OnNow allow an application to enable the wake-up capability of a device.
Notice that enabling a device for wake up will limit the amount of power savings that a sleeping PC can obtain. This is because the system has to keep more devices "on" in order to sense and signal a wake-up event. This might be undesirable in certain circumstances, such as on a battery-powered PC. Applications should ensure that the user is aware of these tradeoffs when enabling wake up by providing information in the user interface for enabling wake up.
BOOL RequestDeviceWakeup(HANDLE hDevice )
| • | hDevice is a handle to a device object or any object on that device (that is, a file or socket object). |
| • | This function returns FALSE if wake up is not supported by the device or if the operating system is putting the system to sleep. |
This device wake-up function can be canceled by the following function:
BOOL CancelDeviceWakeupRequest (HANDLE hDevice )
Wake-Up Latency Function
Applications can specify rough wake-up latency requirements to affect the sleep state that can be entered by using the following function:
BOOL RequestWakeupLatency(LATENCY_TIME latency )
The latency parameter is either LT_LOWEST_LATENCY or LT_DONT_CARE.
To cancel a request, the application uses RequestWakeupLatency(LT_DONT_CARE).
Power Status Functions
Applications can get system power status to tune behavior. The best example of this is the possible work that the applications can do to preserve battery life on mobile PCs. When a PC is running on batteries, the operating system will attempt to put the CPU into a low power state and to spin down the hard disk whenever idle, because the processor and hard disk are two of the highest power devices in mobile PCs. Applications that do not pay attention to the power state of the system can cause the hard disk to spin up frequently, thus loosing all savings gained from turning off the drive.
For a mobile PC, an application can track system status information and then stop non-essential background tasks such as background pagination. To prevent the hard disk from spinning up frequently, the application can postpone low-priority tasks while the PC is running on battery power.
BOOL GetSystemPowerStatus(LPSYSTEM_POWER_STATUS lpSystemPowerStatus )
| • | lpSystemPowerStatus structure indicates an AC or DC power source, battery life remaining, and so on. |
| • | When system power status changes, WM_POWERBROADCAST with PBT_POWER_STATUS_CHANGE is sent. |
This API is available under the Windows 95/98 and Windows 2000 operating systems. Applications can also get the power state of a device to optimize power consumption. For example, by using the following function, an application can postpone low-priority I/O activities if a device is not fully on (that is, if it is in one of its low power states), and then check again later for the status of the evice:
BOOL GetDevicePowerState(IN HANDLE h, IN OUT BOOL *pfOn)
| • | h is a handle to a device object or any object on that device (that is, a file handle). |
| • | This function returns TRUE in *pfOn if device is fully on, FALSE otherwise. |
Other WM_POWERBROADCAST Messages
The semantics for other WM_POWERBROADCAST messages are unchanged from the Windows 95 operating system. For details, see the Microsoft Platform SDK, available through MSDN Professional subscription.