How to Integrate OEM Drivers in Windows Mobile 6.5

Integrating OEM drivers into custom Windows Mobile 6.5 builds was a fundamental process in the mobile device "ROM cooking" community. Enthusiasts and developers took device-specific hardware drivers—such as those for the camera, display, touch panel, and radio interface—from official manufacturer updates and merged them with newer or stripped-down builds of Microsoft's operating system. This process relied on extracting low-level files from stock firmware, formatting them into modular packages, adjusting registry configurations, and using automated ROM "kitchens" to compile a working flashable image.

1. Extracting the Source Drivers

Before drivers could be integrated, they had to be extracted from an official stock ROM or update payload provided by the Original Equipment Manufacturer (OEM) like HTC, Samsung, or Sony Ericsson. Stock ROMs usually came wrapped in executable update utilities or raw binary formats (such as .nbh, .bin, or .tar). Developers dumped these images using tools like nbhcleaner, nbimage, or custom dumping scripts. This separated the operating system into its primary parts: the eXtended Image Package (XIP), which held the kernel and hardware abstraction layer (HAL), and the Image File System (IMGFS), which contained the OS binaries, system files, and OEM-specific drivers.

2. Packaging OEM Drivers

Windows Mobile 6.5 firmware relied on a modular architecture divided into the SYS (the core Microsoft operating system) and the OEM folders. Drivers lived inside the OEM layer and had to follow a standard package structure:

  • Binary Files: The compiled driver files, usually Dynamic Link Libraries (e.g., touch.dll, wavedev.dll, camera.dll).
  • Registry Files (.rgu): Text files containing the exact registry entries required by the Windows Embedded CE subsystem to load the driver during startup. These were typically mapped under [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\].
  • Deployment Scripts (.dsm and .provxml): Device State Manager and provisioning files that detailed package metadata, permissions, and initial initialization settings.

Developers often used a utility called RecMod to deconstruct combined system modules back into flat files so they could be cleanly edited, replaced, or upgraded.

3. Kitchen Organization and Memory Addressing

ROM compilation was managed through software suites known as "ROM Kitchens" (such as the Ervius Visual Kitchen or OSBuilder). Within a kitchen, the driver components were organized into an OEM_Drivers directory.

Because Windows Mobile 6.5 was based on the Windows CE 5.2 kernel, it was restricted by a 32 MB virtual memory slot architecture. Driver integration required precise memory rebasing:

  • Relocation: Tools within the kitchen analyzed the target addresses of all dynamic libraries.
  • Auto-rebasing: The kitchen reallocated base addresses for each OEM .dll to prevent memory collisions in virtual memory Slot 0 and Slot 1, ensuring the device did not experience kernel panics or boot loops on startup.

4. Compiling and Flashing

Once the driver packages were configured with their respective .rgu keys and validated against the updated SYS build:

  1. The kitchen merged the SYS and OEM registries into a singular default system hive (boot.hv and user.hv).
  2. The file system builder assembled the components back into the IMGFS format.
  3. The XIP was patched to ensure that the OEM’s hardware-specific hal.dll and nk.exe properly interfaced with the updated Windows Mobile 6.5 kernel files.
  4. The final payload was packed into a device-specific container (such as an .nbh file).

The resulting custom ROM could then be flashed to the hardware using an unlocked bootloader (such as HardSPL), allowing older hardware to run newer Windows Mobile 6.5 builds with fully functional OEM hardware components.