Building Windows Mobile 6.5 Home Screen Extensions

Windows Mobile 6.5 introduced the "Titanium" interface (internally referred to as CHome), replacing the legacy Today Screen with a touch-friendly, sliding-panel user interface. Developers built custom shell extensions for this interface by combining declarative CPR markup files for visual layouts, registry entries for system registration, and native C++ dynamic-link libraries (DLLs) or background services to manage dynamic content and user interactions.

The CHome Architecture

Unlike earlier versions of Windows Mobile that relied on classic Today Screen plugins rendered via custom window procedures (TodayWindowProc), Windows Mobile 6.5 utilized an XML-based rendering engine. The Titanium shell displayed a vertical list of expandable sliding panels. Each panel could host multiple horizontal pages or items, which updated visually as the user scrolled through them.

Registry Configuration

To register a new extension, developers added keys under the Windows Mobile registry path: [HKEY_LOCAL_MACHINE\Security\CHome]

Developers created a subkey for their custom panel and populated it with metadata, including:

  • Order: A numeric value specifying the vertical position of the panel relative to native items like Contacts, Text, or Calendar.
  • Layout: The name of the layout definition mapping to the custom visual template.
  • GUID / DLL: Associations to native handlers or dynamic data providers.
  • Page Names and Dynamic Variables: Data-bound placeholders (such as titles, notifications, and icon paths) that the engine evaluated at runtime.

Declarative Layout with CPR Files

The presentation layer was defined in CHome Page Resource (.cpr) files stored in the \Windows directory (for example, Titanium_480x800.cpr for WVGA screens). Developers customized these files or defined modular imports to structure their layouts.

Inside the CPR files, developers declared:

  • Layout Templates: Coordinate blocks specifying the bounding boxes, margins, and visibility of text elements and image layers.
  • State Definitions: Distinct visual states, specifically the "Expanded" (selected) state and "Condensed" (unselected) state.
  • Data Tokens: Bracketed variables (e.g., [TEXT1], [ICON]) linking the layout elements directly to values stored in the registry.

Supplying Dynamic Data

Static extensions relied purely on predefined CPR layouts and static registry strings, but interactive plugins required dynamic data injection. Developers achieved this through two main methods:

  1. State and Notification Broker (SNAPI): Developers registered custom state keys. When application data changed (such as receiving a new message or updating weather data), a background process updated these keys, and CHome refreshed the panel UI automatically.
  2. Native C++ Code and Hooks: Advanced extensions hooked into device APIs using the Windows Mobile SDK. By writing native Win32/C++ DLLs, developers handled hardware key presses, triggered animations, launched external executables when a user pressed the action button, and manipulated the CHome window tree directly.

Packaging and Installation

Extensions were packaged into standard Cabinet (.cab) files. The installer deployed layout assets and icon graphics to \Windows, added the necessary registry entries to instantiate the panel, and triggered a reload of the Titanium shell without requiring a full device reboot by querying and refreshing the cprog.exe process.