Dual-SIM Management on Windows Mobile 6.5

This article examines how rare Windows Mobile 6.5 devices implemented dual-SIM functionality despite the operating system lacking native multi-SIM architecture. Because Microsoft designed Windows Mobile 6.5 around a single cellular radio paradigm, third-party manufacturers had to engineer custom Radio Interface Layers (RIL), proprietary hardware multiplexers, and bespoke user interfaces to route calls, data, and messaging across two SIM cards simultaneously.

The Architectural Limitation of Windows Mobile 6.5

Windows Mobile 6.5 relied on the Windows CE 5.2 kernel and the CellCore subsystem to handle telephony. CellCore was architecturally hardcoded to communicate with a single Radio Interface Layer (RIL) driver, exposing only one instance of the Telephony API (TAPI) to the operating system. Consequently, the core OS had no native awareness of secondary SIM slots, dual IMEI configurations, or alternating network states.

Dual RIL and Middleware Multiplexing

To circumvent the single-radio limitation, Original Design Manufacturers (ODMs) such as Gigabyte (with the GSmart series), General Mobile, and various Asian white-label manufacturers developed custom RIL proxy drivers.

Instead of passing commands directly to a single modem, the manufacturer's custom ril.dll acted as a multiplexer. This driver sat between the Windows Mobile CellCore architecture and the underlying baseband hardware:

  • Command Interception: The custom RIL intercepted standard AT commands generated by CellCore and appended manufacturer-specific prefixes to direct actions to SIM 1 or SIM 2.
  • Virtualization: To the OS, the modem appeared as a single device, but the driver maintained two distinct state machines tracking registration status, signal strength, and network operator information for each card.

Hardware Implementations: DSDS vs. DSDA

Hardware manufacturers implemented dual-SIM capabilities using two distinct architectures:

  1. Dual SIM Dual Standby (DSDS): The most common and cost-effective approach utilized a single baseband processor connected to two SIM slots via an electronic switch. The radio listened to the paging channels of both networks in a time-sliced manner while in standby. When a call was active on one SIM, the radio dedicated its entire transceiver to that call, causing the inactive SIM to become unreachable.
  2. Dual SIM Dual Active (DSDA): Found on high-end or specialized devices, this design featured two discrete radio transceivers or a specialized dual-baseband chipset. Each SIM operated independently with its own RF path and IMEI. Users could receive calls on SIM 2 while engaged in an active call or data session on SIM 1. Managing this required the custom RIL to handle concurrent data and voice interrupts simultaneously without crashing CellCore.

Custom Dialers and UI Shells

Because the native Windows Mobile dialer (cprog.exe) had only a single "Talk" button and one signal indicator, hardware makers had to completely replace or heavily patch the standard phone interface:

  • Dialer Replacements: Manufacturers wrote custom dialer applications featuring dual "Send" buttons (e.g., "Call SIM 1" and "Call SIM 2"). These dialers bypassed standard TAPI triggers, communicating directly with the proprietary RIL extension APIs.
  • Dual Signal Meters: OEMs replaced the standard Windows Mobile title bar icons with custom shell components that displayed two distinct signal bars labeled "1" and "2," along with separate indicators for 2G/3G connectivity.
  • Control Panel Applets: A dedicated configuration applet was added to the Windows Mobile Settings menu. This allowed users to designate a primary SIM for packet data, set default SIMs for outgoing calls, rename SIM profiles, or disable a specific SIM slot without rebooting the device.

Handling Cellular Data and SMS

Packet-switched data (GPRS/EDGE/HSDPA) was strictly limited by hardware constraints. Most dual-SIM Windows Mobile devices allocated 3G capabilities exclusively to SIM 1, while SIM 2 was restricted to 2G networks. The custom middleware enforced a rule where only one SIM could maintain an active PDP (Packet Data Protocol) context at any given time, preventing IP routing conflicts within the Windows CE network stack.

Short Message Service (SMS) management required OEM hooks into the MAPI (Messaging Application Programming Interface) store. Incoming text messages were tagged with custom metadata indicating the receiving SIM. When a user replied, the messaging client read this metadata to automatically select the matching SIM for transmission, maintaining conversation consistency without requiring OS-level multi-SIM support.