February 28, 2021
Hot Topics:

CE Power Conservation Strategies

  • By Nancy Nicolaisen
  • Send Email »
  • More Articles »

How to Make Sure You Don't Sidestep the System's Power Conservation Defenses

As you've seen in examples so far, a great deal of the effort involved in porting Win32 from the desktop to a CE device has to do with redefining application strategy. Put another way, there are a lot of Win 32 strategies that we choose to omit or modify because they are incompatible with the scale of Windows CE. In addition to the PeekMessage() example shown above, there are a few other desktop practices that can have dramatic consequences for power consumption. Here are three types of behavior you should approach with care.


Threading is a highly complex application behavior. Chances are good that if you went to the trouble of implementing a design that included threading on the desktop, it was the only workable solution in that context. The key danger on CE is the chance of creating threads that have a tendency to be or become non blocking. On Windows CE, only an application's main thread can receive messages, and the modifying parameters used to create threads are much less numerous than on the desktop. Also, threads are not allowed to outlive the process that creates them. You may find the CE threading model doesn't support a straight across port of your desktop design. If this turns out to be the case, consider omitting features that require threading.

If you choose to use threading, here are two caveats:

  • Use mutexes or events to force threads to block when they are not engaged in their intended task.
  • Test threaded code on the full range of physical devices you intend it to target.

Timers and Other Polling Behaviors

On the desktop, we can afford to implement "polling" behaviors, where every time a given interval elapses, we check status information on something. By its very nature, polling is inefficient because, for the vast majority of iterations, you'll make a test that tells you it's time to do nothing and check again later. Very often, timers are set for this purpose on the desktop. Check the code you are porting to see whether it processes the WM_TIMER message or calls the SetTimer() function. Either of these may be the source of application behavior that tends to defeat attempts to idle the processor, causing diminished battery life.


Spinning is a kind of looping that unintelligently persists until some arbitrary threshold is met. Here's a loop that spins.

   //do something or other
   if( bBoredSensless )
      { break; }

This kind of behavior is terrible for battery life because the processor is active for 100% of the thread's scheduled timeslice. Unfortunately, it is harder to find a spinning loop in a body of code than to find timers or multi threading. If your ported code seems to drain the batteries on a CE device noticeably, look for while()s that have a constant as the parameter and for( ; ; ) where either the comparison or the action clause have an unusual or constant form.

Looking Ahead

One of the great strengths of Windows CE is the ease with which it allows you to integrate handheld and desktop devices. In the next lesson, we'll begin to explore the tools which enable this behavior: The Remote Application Programming Interface, RAPI.

About the Author

Nancy Nicolaisen is a software engineer who has designed and implemented highly modular Windows CE products that include features such as full remote diagnostics, CE-side data compression, dynamically constructed user interface, automatic screen size detection, and entry time data validation.

In addition to writing for Developer.com, she has written several books, including Making Win 32 Applications Mobile.

# # #

Page 2 of 2

This article was originally published on May 12, 2004

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date