Microsoft Corporation
December 4, 1998
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.
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 short 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 application programming interface (API) 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 for exciting new features in Win32-based applications include the following:
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.
Following is a summary of what can be done now to design applications that take advantage of the "always on" OnNow-capable PC platform:
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.
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:
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.
The OnNow extensions to the Win32 APIs fill two roles:
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.
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 section summarizes key information about these new functions and messages.
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.
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:
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.
This API was implemented in Windows 95. Original equipment manufacturer (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.
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 autosave 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:
The following sleep state notification messages are implemented in Windows 95/98 and in Windows 2000.
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†† | Reopen files that were closed before sleep. |
†† Also available for use in the Windows 95 operating system.
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.
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)
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 with 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.
This device wake-up function can be canceled by the following function:
BOOL CancelDeviceWakeupRequest (HANDLE hDevice)
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).
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 losing all savings gained from turning off the drive.
For a mobile PC, an application can track system status information and stop nonessential 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.
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 device:
BOOL GetDevicePowerState(IN HANDLE h, IN OUT BOOL *pfOn)
The following APIs are provided for message indicators and power management messages.
The "Designed for Windows" logo program requires that all PCs have message-waiting indicators on the front of the computer. This allows computers that download e-mail, voice messages, faxes, and so on to indicate to the user that new messages have arrived. Applications can take advantage of this feature by calling SetMessageWaitingIndicator:
BOOL SetMessageWaitingIndicator(IN HANDLE hIndicator, IN ULONG cmsg);
The application passes in the current number of messages the application has waiting. The operating system will combine this number with the number from all other applications in the system and will update the computer's message-waiting indicator with the total. To change the number of messages, an application simply calls SetMessageWaitingIndicator with the new number, which can be 0 to clear the application's message-waiting count. (hIndicator is a handle to the message indicator device. Applications can get this handle by calling CreateFile on the "\\.\MessageIndicator" device).
The operating system tracks calls to SetMessageWaitingIndicator on a per-handle basis. If the process exits either normally or abnormally, the operating system will automatically close all handles, automatically reducing the system message-waiting counter by the amount specified in that application's last call to SetMessageWaitingIndicator.
If the system does not have a message waiting indicator, then SetMessageWaitingIndicator returns FALSE.
All the power-management notifications are sent in the WM_POWERBROADCAST messages. Normally, these are sent to applications with Windows message functions. However, Win32 console applications or Windows 2000 Service applications also need to be aware of these events. To receive these messages, non-Windows applications can call RegisterSysMsgHandler to register a message handler to receive Plug and Play and power management messages.
The semantics for other WM_POWERBROADCAST messages are unchanged from the Windows 95 operating system. For details, see the Microsoft Platform SDK.