Data Persistence with the RAM-based Registry Using the OAL (Windows CE 5.0)
The RAM-based registry supports two OAL-based save-and-restore methods. OEMs can use these methods to persist registry data when the RAM, which contains the object store, is not being powered. In addition, the methods can also be used to provide protection against invalid data configurations. The preferred method for persisting data with the RAM-based registry is to include the OEMRegistry.dll sample file in your OS image. For more information, see Persisting Data with the RAM-Based Registry.
The first method is based on the RegCopyFile and RegRestoreFile functions. RegCopyFile saves the entire registry to a file, and RegRestoreFile sets up the registry to be replaced with the data in the given file on the next boot. To persist the registry when a device is turned off, an OEM would first use RegCopyFile to save the data to a persistent file. On the next cold boot, the OEM would call RegRestoreFile to prepare the registry to be replaced with data in the file, and perform a warm reboot to complete the registry replacement. This manner of registry persistence is easy to implement, but because it requires a dual boot to restore the registry after a device was turned off, it is relatively slow. The RegCopyFile and RegRestoreFile method is better suited to providing backup to protect against errors than it is to providing registry persistence.
The second method gives the OEM responsibility for persisting the data. An OEM can implement the WriteRegistryToOEM and ReadRegistryFromOEM functions in the OAL. These functions, if implemented, are called by the registry code to save and restore the data. When an application calls the RegFlushKey function, the OS makes a series of calls to WriteRegistryToOEM to pass the entire registry to the OEM, which stores the data on any persistent media. Then while the OS is booting, it makes another series of calls to ReadRegistryFromOEM to receive the data from wherever the OEM stored it. The difficulty in using this mechanism is that file system calls, such as CreateFile, ReadFile, and WriteFile, cannot be used to read the data from storage during ReadRegistryFromOEM. While they can be used during WriteRegistryToOEM, the block and file system drivers needed to read from external media are not started until after the registry is initialized. Therefore, implementing ReadRegistryFromOEM is difficult; code to read from the persistent media must be added to the OAL. But this mechanism has the benefit of requiring only a single boot to restore the registry, as opposed to the dual boot required by the RegCopyFile and RegRestoreFile mechanism.
The following pairs of functions cannot be intermixed: RegCopyFile and RegRestoreFile, and WriteRegistryToOEM and ReadRegistryFromOEM. The file produced by RegCopyFile is not the same as that produced by WriteRegistryToOEM.
See Also
RAM-Based Registry | RAM-Based Registry Setup | RegCopyFile | RegRestoreFile | WriteRegistryToOEM | ReadRegistryFromOEM | RegFlushKey | Persisting Data with the RAM-Based Registry
Send Feedback on this topic to the authors