Windows Mobile 6.5 Widget Hardware APIs Explained

Windows Mobile 6.5 introduced an embedded widget engine that allowed developers to build lightweight applications using HTML, CSS, and JavaScript. To bridge the gap between standard web code and native mobile hardware, the runtime exposed specialized JavaScript APIs connected to the underlying Windows CE operating system. This article details the architecture, dispatch mechanisms, and security protocols that enabled JavaScript to communicate with physical device hardware such as the battery, network radios, and notification systems.

The Widget Host and the Web Engine

The Windows Mobile 6.5 widget architecture relied on the Internet Explorer Mobile (Trident/MSHTML) rendering engine encapsulated inside a native host executable (typically widget.exe). Standard web browsers isolate JavaScript within a sandbox to prevent direct access to operating system memory and hardware. However, the widget host extended the script engine's global namespace, injecting custom objects directly into the DOM tree. This allowed standard JavaScript code to call custom methods and read properties mapped directly to native runtime services.

The Native Bridge: COM and IDispatch

The communication layer between JavaScript and the physical device relied on Microsoft’s Component Object Model (COM) architecture.

  1. Script Engine Registration: During initialization, the widget container instantiated native C++ COM objects that implemented the IDispatch interface.
  2. Object Exposure: These COM objects were exposed to the JavaScript runtime as properties of native objects (such as the standard widget object or Microsoft-specific extensions).
  3. Dispatch Invocation: When a script executed a hardware call—such as checking the battery percentage or toggling vibration—the script engine translated the JavaScript function call into an IDispatch::Invoke call in the native C++ layer.
  4. Kernel/Driver Interaction: The native C++ wrapper translated the parameters, invoked the corresponding Windows Embedded CE / Win32 APIs (e.g., GetSystemPowerStatusEx2 for battery status), and returned the hardware values back across the COM bridge into JavaScript primitives.

Supported Hardware Interfaces

Through this architecture, widgets could query and interact with several device components:

  • Power and Battery: Developers could monitor battery levels, AC power connections, and charging states without polling external native services.
  • Network and Connectivity: APIs allowed scripts to detect active connection types (GPRS, 3G, Wi-Fi) and monitor signal strength to adapt data fetching strategies.
  • Notifications and Haptics: The engine allowed scripts to trigger hardware-based notification mechanisms, such as activating the device’s vibration motor, blinking status LEDs, or playing local audio alerts.
  • Display and Orientation: Basic screen metrics, display orientation changes, and screen resolution properties were mirrored to the runtime for responsive widget layouts.

Security and Sandboxing

To prevent malicious scripts from abusing hardware features, Windows Mobile 6.5 implemented a security model based on the W3C Widgets specification. Access to device hardware was controlled through the widget's config.xml manifest file.

Widgets had to declare the specific features or APIs they intended to use. During installation, the operating system checked these requests against security policies and digital signatures. If an unsigned or untrusted widget attempted to access privileged hardware-level APIs without explicit permissions, the native COM layer rejected the dispatch call, returning a script error and safeguarding system resources.