Consumer appliances typically do not burden the user with much of this. Yes, a consumer must know things like how much video tape is left before recording a program with their VCR, but it doesn't go much beyond that. Obviously, the PC experience has been maturing over the last 20+ years. Computers are much easier to use than they were even five years ago. However, with all the advancement in programming practices, increased memory, storage, and CPU power, the user is still left to manage the system resources. Leaders in the PC industry,such as Microsoft, have come to realize that it is time to fold this responsibility into the software. The Auto PC is one of the first products that attempts to take responsibility for its resource management. A cornerstone of that effort is the Running Application Model.

Guidelines for implementing the Running Application Model
On any computer, a running application knows when the user is interacting with it. The Running Application Model requires each application to take that knowledge and make use of it in managing its resource usage. For instance, if the application is not in the foreground (i.e., it doesn't currently own the display, keypad, Speech Recognition), then it should free up as many resources as it can until the user needs it again. For some applications, this can mean simply exiting when the user switches away and restarting when the user switches back. For others, this might mean freeing up memory used for caching information and providing fast user feedback when the application is in the foreground. Still, others might not be able to free up any memory but can drastically reduce their CPU usage. The following guidelines can be used to help an Auto PC software developer make his or her software a good citizen by participating in the Running Application Model.

Exit strategy
Generally speaking, applications should always try to exit when the user switches away from them, either immediately or after some period of idle time, if at all possible. Obviously, applications that do background processing like the CD Player or Navigation can't do this until they are no longer doing their background processing.

Implement Fast App Start
When an application is launched on the Auto PC, it has about 1.5 seconds to call RegisterStartedApplication before it gets put on the Auto PC's suspicious behavior list. After 20 seconds, if the application has not registered, the Auto PC will terminate the application. The goal here is that all applications give the user either a visual or auditory response before 1.5 seconds expires. This can mean that your main application initialization doesn't happen for some time after the 1.5 seconds, but getting the splash screen up is important. Fast application startup is especially important if your application exits each time a user switches away from it.

Fully implement WM_CLOSE support
When your main application message loop gets a WM_CLOSE message, it's from the Auto PC requesting that your application save its state and shut down immediately. If your application is requested to close but cannot because it's busy, at least have it go into some form of WM_HIBERNATE until the application is activated again. It's important to keep in mind that an application that chooses not to close down or does not close down in three seconds may simply be terminated by the Auto PC. This forced termination usually happens when the user is installing an upgrade to your application.