Windows Mobile 6.5 XIP and ROM Modules Explained

This article examines the internal architecture of Windows Mobile 6.5 ROM images, focusing specifically on the mechanics of Execute in Place (XIP) and ROM modules. It explores how Windows CE 5.2—the underlying core of Windows Mobile 6.5—structured its binary images to overcome strict memory constraints, detailing how the operating system separated read-only code from writable data to maximize system performance and conserve volatile system memory.

The Windows Mobile 6.5 ROM Architecture

A Windows Mobile 6.5 image (typically flashed as an NBF or NB0 file) is divided into distinct functional layers: the bootloader components, the core kernel partition (XIP), and the system/extended partitions (SYS and EXT). The entire system relies on the Windows CE image building tool, Romimage.exe, which processes configuration files (primarily config.bib) to allocate exact physical and virtual memory locations for all operating system components before the image is flashed to the device.

Execute in Place (XIP) Mechanics

Execute in Place (XIP) is a method that allows the CPU to execute instructions directly from non-volatile storage or dedicated flash memory regions without copying the executable code into Random Access Memory (RAM) first.

In Windows Mobile 6.5, the XIP region contains the lowest-level operating system components:

  • NK.exe (the Windows CE kernel)
  • The Hardware Abstraction Layer (HAL / OEM Adaptation Layer)
  • Critical boot drivers and memory management routines

When a device boots, the Memory Management Unit (MMU) maps the physical addresses of the XIP flash region directly into the kernel's virtual address space. Because the code is executed directly from its mapped location, the device avoids the overhead of reading executables into RAM pages. This design drastically reduced boot times and kept the operating system's baseline RAM footprint to a minimum—a critical factor for hardware platforms often limited to 128 MB or 256 MB of total RAM.

ROM Modules vs. Files

Within a Windows Mobile 6.5 image, assets are stored either as flat "Files" or as processed "Modules":

  1. Flat Files: Items like images, ringtones, and uncompressed data are stored as raw binary blobs. If an executable is stored as a file, the entire binary must be decompressed and loaded into RAM to execute.
  2. ROM Modules: Dynamic Link Libraries (.dll) and Executables (.exe) compiled into the image are converted into ROM modules during the build process by Romimage.exe.

When a binary is converted into a ROM module, its Portable Executable (PE) header is stripped and parsed into two distinct parts:

  • Code Sections (Read-Only): The module's text and execution logic are pre-relocated to specific virtual memory addresses. Because this memory is static and read-only, it can be executed in place directly from ROM/flash, leveraging demand-paging via the MMU without consuming RAM.
  • Data Sections (Read/Write): The module's read/write data, stack, and heap segments cannot remain in read-only storage. When the module is initialized, the kernel allocates small slices of RAM exclusively for these writable sections.

The Role of Configuration Files

The integration of XIP and ROM modules was managed through Binary Image Builder (.bib) files. The config.bib file defined memory regions:

  • MEMORY: Designated RAM areas for dynamic allocations and writable sections.
  • ROMSIZE: Fixed regions where ROM modules and XIP code physically resided.

The MODULES section of the .bib file marked which components should be parsed into the module structure rather than stored as regular files. During execution, the Windows Mobile 6.5 kernel handled ROM modules as first-class citizens, routing execution pointers straight to the ROM address space while handling page faults seamlessly through the file system and paging drivers.