Customizing the Out of Memory User Interface Component

The Out of Memory User Interface (Oomui) component controls the appearance of the Graphics, Windowing, and Events Subsystem (GWES) out-of-memory handler and enables a user, or the system itself, to take action to prevent data loss or other problems related to out-of-memory conditions.

By default, Oomui displays a window indicating that the system memory is insufficient for the task being performed. The user is then prompted take action to free some memory, for example, by closing applications or moving some memory currently allocated to the object store so it can be used by the program.

By replacing Oomui with a custom out-of-memory component, you can adjust this window to the screen size of your device. You can also add functionality to this component, for example, to cause the system to automatically close noncritical applications and perform other system cleanup tasks in the absence of a user.

To customize the Oomui component, modify and rebuild the code located in %_WINCEROOT%\Public\Common\Oak\Drivers\Oomui. An out-of-memory UI component must implement the following functions, as defined by the Oomui.h header file:

• OomUI_CreateNotRespondingWindow
• OomUI_CreateOomWindow
• OomUI_FShowOomWindow
• OomUI_Initialize
• OomUI_NotRespondingWndProc
• OomUI_OnShow
• OomUI_OomWndProc
• OomUI_SetWindowsInfo

In addition, the Oomui component uses the following functions:

• OomUICallback_CloseWindow
• OomUICallback_IsCritical
• OomUICallback_NonClientPaint

The thread that runs the Out of Memory window runs at priority THREAD_PRIORITY_HIGHEST by default. When an out-of-memory condition occurs and the Out of Memory window is displayed, no lower priority threads are allowed to run. Preventing all lower priority threads from running causes all applications to be suspended so that they do not continue to consume memory while the Out of Memory window is displayed. You should avoid making calls that use a large amount of memory and that try to communicate with other threads. These calls may fail or lock up because of the unusual state of the system.

You can set the priority of the thread that runs the Out of Memory window by setting the HKEY_LOCAL_MACHINE\SYSTEM\GWE\ThreadPriorities\Oom registry key to the priority level that you want, for example:

[HKEY_LOCAL_MACHINE\SYSTEM\GWE\ThreadPriorities]
    "Oom"=dword:fb

When the system is in a state of standard operation and memory is not low, the thread that runs the Out of Memory window is not in a message loop. This means that the Oomui component should not create any windows other than those specifically requested by the system.

Because user input is necessary for interaction with the Out of Memory window, device driver threads running in drivers such as the keyboard and touch screen drivers need to run at a priority of THREAD_PRIORITY_HIGHEST.

When an out-of-memory condition occurs, the operating system (OS) calls the DdsiTouchPanelSetMode touch driver function with iIndex equal to TPSM_PRIORITY_HIGH_ID just before the Out of Memory window becomes active. At this time, the touch driver should raise its priority to THREAD_PRIORITY_HIGHEST. When complete, the out-of-memory process calls the DdsiTouchPanelSetMode touch driver function, setting iIndex to TPSM_PRIORITY_NORMAL_ID and lpInput to NULL. The touch driver should then return its priority to THREAD_PRIORITY_NORMAL.

To ensure that BeginPaint does not fail in low-memory conditions, out-of-memory UI components have cache device contexts (DCs). You can adjust how many DCs to cache by modifying the code in %_WINCEROOT%\Public\Common\Oak\Drivers\Oomui\Oomuil.cpp. By caching DCs, GWES resources can be released before BeginPaint is called.

See Also

Customizing a UI Component

Last updated on Wednesday, April 13, 2005

© 2005 Microsoft Corporation. All rights reserved.