[Mike Dimmick]

Desktop/Server Windows' HAL is a very broad brush at the very lowest level. Most PCs will run exactly the same HAL. What makes the OS adaptable to the hardware is drivers.

The Windows CE equivalent of the HAL is the OAL, OEM Adaptation Layer. It's sometimes also called a Board Support Package (BSP) - a number of BSPs for stock boards are available. OEMs rarely use these development boards directly, though, so the BSP will need to be adapted to the device.

To save space, some components - such as graphics and keyboard drivers - are compiled directly into their hosts, since the graphics chip is obviously not replaceable on a PDA. It could be done as a loadable module but, in practice, usually isn't. Also, the exact way in which the devices are wired up may not be identical between PDAs with the same chip, and that can have an effect on the system (example: a graphics chip might not appear at the same physical address on two different systems). There's no master plug-and-play system on handhelds - only PCMCIA and SD cards support plug-and-play. Everything else has to be set up correctly at ROM build time.

The problem for driver upgrades is that Microsoft haven't focused that closely on keeping the driver model identical between major versions. This allows the model to be changed more readily to accommodate new features, at the cost of drivers needing to be rewritten at least in part to match the new model. It's not as simple as just reusing the same binary on the new device.

AKU updates - minor versions of an OS, where the driver model doesn't change - are relatively easier, but the OEM may still decide that they need to revalidate the device completely, and the networks or regulatory authorities may require it.

We're currently trying to get an OEM to replace the version of .NET Compact Framework in ROM on an enterprise device with version 2.0 SP2, with the unmanaged DLLs set to Execute In Place, in order to recover 1.1MB of virtual address space. To do this they have to get MS to sign the update package. Unfortunately their first pass only saved 300kB because they got the base addresses wrong, and mscoree2_0.dll (870kB) ended up located at the top of memory, rather than in the 'hole' where the previous version lived.