The Windows Mobile device shell uses the Windows Embedded CE WM_HIBERNATEmessage as one mechanism for asking applications to free memory. The system posts this message to one or more applications, beginning with the application that has been inactive the longest. It requests memory from the active application last and does not send WM_HIBERNATEmessages to invisible windows.

Note:
Because the shell closes applications automatically, you do not need to use the Windows Embedded CE WM_HIBERNATEmessage. However, if you choose to use it, your application does not need to restart as often.

When the system brings an application to the foreground, it sends a WM_ACTIVATEmessage. If the started application has released memory through hibernation, the system does not restore its memory resources to the pre-hibernation state. Applications must have a WM_ACTIVATEhandler that can handle the restoration of memory resources following hibernation.

An application must take the following actions when it receives a Windows Embedded CE WM_HIBERNATEmessage:

• Free any large blocks of memory allocated by VirtualAlloc— for example, a cache.
  
  
• Free as many Graphics, Windowing, and Events Subsystem (GWES) objects as possible, including windows, bitmaps, and device contexts.
  
  
• Save the state of the heap to restore it later, and then free the entire heap.
  
  

As the amount of available memory drops, the system posts Windows Embedded CE WM_HIBERNATEmessages at an increasing rate. If the system reaches a point where a call to VirtualAllocis about to fail, it tries to free pages by shrinking other application stacks that are running in the background. The system shrinks these background stacks in random order to minimize the risk of a stack fault in your active application, which would cause your application to fail. The system also frees memory by discarding read-only pages. If the system cannot free any stack pages, VirtualAllocfails and the function is returned to the application as a failed function call.

See Also