How Windows Mobile 6.5 SIP Keyboards Worked

Windows Mobile 6.5 relied on the Software Input Panel (SIP) framework to provide on-screen virtual keyboards and text input methods on touchscreen devices. This system operated as an extensible OS-level architecture that decoupled input rendering from application logic, allowing users to alternate between full QWERTY keyboards, handwriting recognition engines, and specialized third-party input tools. By translating touch events into standard Windows message streams, the SIP allowed resistive touchscreen devices to accept precise text input across legacy and touch-optimized applications alike.

The Architecture and COM Integration

At the core of the Windows Mobile 6.5 SIP was a Component Object Model (COM) framework based on the underlying Windows CE kernel. Every virtual keyboard or input tool was implemented as an in-process COM server exposing the IInputMethod or IInputMethod2 interface.

When an editable field received focus, the OS shell loaded the active SIP dynamic link library (DLL) into the system's memory space. The SIP framework managed a dedicated window handle created specifically to host the input interface. When a user tapped a virtual key, the SIP component did not interact directly with the targeted application; instead, it called system helper functions such as IIMCallback::SendVirtualKey or generated standard Windows input messages (WM_KEYDOWN, WM_KEYUP, and WM_CHAR). These messages were injected directly into the active window's message queue, making virtual input functionally identical to physical hardware keyboard strokes.

Stylus Interaction on Resistive Hardware

Most Windows Mobile 6.5 devices used resistive touch panels, which required physical pressure to register an input coordinate. Consequently, the native SIP was designed primarily for single-point stylus tapping rather than finger-based typing.

The software calculated inputs based on precise coordinate mappings within the SIP window. Tapping a key triggered an immediate visual state change—often inverting key colors or drawing a slight pop-up—followed by the immediate release of the character code. Because resistive digitizers could not register multitouch events, the default SIP prohibited simultaneous key presses, such as holding "Shift" while tapping a letter; instead, the system treated modifier keys as sticky toggles that remained active until the subsequent character was typed.

Screen Management and Window Resizing

Because mobile screens in the Windows Mobile era typically featured low resolutions such as QVGA (240x320) or WVGA (480x800), the SIP occupied a significant percentage of visible screen real estate. The operating system actively managed this through the SIPINFO structure and shell notifications.

When the SIP was deployed, the system sent a WM_SETTINGCHANGE message to top-level windows to notify running applications of a change in the visible desktop area (the work area minus the SIP rectangle). Well-designed Windows Mobile applications listened for this message and adjusted their child control layouts or scrolled active input fields into view so the keyboard would not obscure the text the user was typing.

Extensibility and Input Switching

The SIP architecture was fully modular, accessible via a small keyboard icon located on the bottom navigation bar. Tapping the arrow adjacent to this icon allowed users to hot-swap between different input components on the fly, including:

  • Default Keyboard: A standard, compact layout optimized for stylus point-and-tap typing.
  • Letter Recognizer and Block Recognizer: Gesture-based engines that translated specific single-stroke glyphs (reminiscent of Palm OS Graffiti) into text.
  • Transcriber: A full-screen handwriting recognition tool that allowed users to write natural sentences across any part of the screen using a stylus.
  • Third-Party Keyboards: Hardware manufacturers (such as HTC) and third-party developers created custom capacitive-friendly, finger-spaced keyboards, predictive text engines, and swipe-style input systems by implementing the standard IInputMethod interfaces.