Fully implement WM_HIBERNATE support
The WM__HIBERNATE message is sent to your application when system resources are running low. Wparam and Lparam will be equal to 0. Your application should attempt to release as many resources as possible upon receiving this message by unloading forms, deleting drawing objects, or freeing up as much memory as possible without killing the internal state. If wParam equals 1, then the application has been in the background for more than ten minutes with the system in the power on state. Your application should exit if no longer in use.

State saving and restoration
Design your applications so they are able to save their state at most any time and exit. When they start they should restore their state quickly. This will be instrumental in implementing WM_CLOSE and WM_HIBERNATE.

Memory allocation
When possible, allocate all the memory and storage you will need entirely up front. If that isn't reasonable, try allocating it in large chunks rather than each time a user operation needs a little more memory. The idea behind this is to avoid getting into a situation where your application can't save the user's data because storage is gone, or the user can't proceed with some operation because there isn't enough memory. This usually means not giving the user the ability to create an unlimited number of data items, but restricting them to a fixed count. An example is limiting radio station presets to 20 versus an unlimited amount, or available contacts to 500 versus an unlimited amount. This will also simplify your code because you don't need to deal with as many resource allocation failure errors. Again, this protects the user from having to know about resource management.

Time measurement
Use GetIdleTime and GetTickCount to measure how much free time the CPU has before beginning an intensive operation. You can use these two values to determine what the processor load is by dividing the delta of two GetIdleTime values taken at a period of some fixed number of milliseconds, measured by using GetTickCount. The delta divided by that period is the percent utilization. Your application can use this information during runtime to determine how CPU intensive of an algorithm it might be able to use at any given period. For instance, if your application is displaying animation along with MP3 playback, maybe it reduces the animation frame rate when the CPU is relatively saturated.

Avoid the background blues
Avoid using tight polling loops, elevated priorities, or any unnecessary computing, such as painting, when your application is in the background. Remember, you are sharing the computing power, so do everything within reason to reduce the load your program places on the CPU, memory and storage.

Conclusion
By implementing the Running Application Model, your application will have taken a major step toward being fully compliant with the Auto PC programming model. This will help give the end user a more consumer-oriented experience. Your application will work more cooperatively with the other applications and, thus, the system as a whole will perform better for the user. It's a real shift in thinking for many programmers to start hiding the complexities of resource management issues from the end user. With today's powerful processors, abundant memory, and advanced programming methods, it's time application developers start shielding the user from this sort of burden. The Auto PC provides an ideal environment to flex your programming muscle and provide software that delivers a consumer level experience.

Do you have questions or comments? Please email me at markmo@autopcware.com.