Push Notifications in Windows Mobile 6.5

Before the advent of modern unified cloud messaging architectures like Apple Push Notification service (APNs) or Firebase Cloud Messaging (FCM), developers building for Windows Mobile 6.5 had to engineer custom, decentralized solutions to deliver real-time updates. This article explores the primary mechanisms developers used to achieve push functionality on the platform, including Microsoft's Exchange ActiveSync Direct Push, custom persistent TCP connections, silent SMS triggers, and background polling routines managed by the Windows CE architecture.

Microsoft Direct Push via Exchange ActiveSync

For enterprise messaging, contacts, and calendar synchronization, Microsoft provided a native architecture called Direct Push, integrated into Exchange Server 2003 SP2 and Windows Mobile 5.0 through 6.5.

Instead of traditional periodic polling, Direct Push relied on an optimized HTTP/HTTPS long-polling model:

  1. Heartbeat Request: The mobile device established a secure connection to the Exchange Server via Exchange ActiveSync (EAS) and issued a PING command specifying folders to monitor and a heartbeat interval (typically between 8 to 15 minutes).
  2. Held Connection: The server held the request open. If changes occurred on the server within that window, the server immediately responded with a notification indicating which folder changed.
  3. Dynamic Heartbeat Adjustment: If no changes occurred, the server returned an HTTP 200 at the end of the interval, and the device immediately sent another PING. The device algorithm dynamically increased or decreased this heartbeat interval to adapt to cellular network NAT (Network Address Translation) timeouts without draining the battery.
  4. Data Sync: Upon receiving a notification response, the device initiated a standard sync command to fetch the modified items.

Custom Persistent TCP Sockets

Developers building third-party chat or real-time applications could not rely on EAS infrastructure and often implemented custom persistent socket connections using the Windows Sockets (Winsock) API in native C++ or the .NET Compact Framework.

To make this work within mobile network constraints:

  • Background Services: Developers created headless background processes (often implemented as services managed by services.exe) that ran continuously.
  • Keep-Alive Packets: Cellular carriers frequently terminated idle TCP connections via aggressive NAT firewalls. Background services had to transmit minimal "keep-alive" packets at intervals just shorter than the carrier's timeout window (often every 5 to 10 minutes) to maintain the socket.
  • Radio State Management: Keeping the radio continuously in a high-power state rapidly drained the device's battery. Developers had to coordinate socket traffic with the Windows Mobile Connection Manager to avoid unnecessary radio wake-ups.

Silent and Binary SMS Triggers

Another widely used pattern involved using the cellular signaling channel rather than a continuous IP connection. This was common for low-frequency, high-urgency notifications.

  • Binary SMS / WAP Push: A server-side component sent a specially crafted, user-invisible binary SMS or WAP Push message to the device's phone number.
  • SMS Router Interception: Windows Mobile featured an SMS message routing architecture. Applications registered a custom rule using the MAPI architecture or the SmsOpen and SmsSetMessageNotification APIs.
  • Application Wake-Up: When the targeted SMS arrived, the OS intercepted it without displaying an alert to the user or writing it to the inbox. The background daemon processed the payload, extracted the update instructions, activated the device's main application, or opened a temporary IP connection to retrieve data.

Scheduled Background Wake-Ups

When continuous connections were too costly for battery life, developers simulated push notifications through scheduled execution using the Windows CE Notification Engine.

  • CeRunAppAtTime API: Developers used this native API to schedule an application or background executable to run at a specific time.
  • State and Notification Broker: Windows Mobile included a broker that tracked system events, such as changes in network connectivity or cradle docking. Developers registered their applications to wake up upon specific state changes, fetch pending updates from a server, display a notification bubble via the SHNotificationAdd API, and return the device to sleep.