SUMMARY
This article pertains to the RAM-based (or object store-based) registry, which was the sole registry available in Windows CE versions before Windows CE .NET. The RAM-based registry is an optional component in Windows CE .NET.
The RAM-based registry stores its data in the object store, which resides in random access memory (RAM). The data persists as long as power is maintained in the RAM (even when the device is off), but the data is lost if RAM is not powered. Providing power to the registry at all times is not always desirable. Therefore, the RAM-based registry contains some mechanisms for persisting the data by writing to other storage media. This article is an overview of the available options and how those mechanisms work.
In all versions of Windows CE, the RAM-based registry supports a save-and-restore mechanism based on the application programming interfaces (APIs) RegCopyFile and RegRestoreFile. RegCopyFile saves the whole registry to a file. RegRestoreFile sets up the registry for replacement with the data in the specified file on the next boot. To persist the registry when a device is powered off, an OEM must first use RegCopyFile to save the data to a persistent file. Then, on the next (cold) boot, the OEM calls RegRestoreFile to prepare the registry for replacement with the data in the file. Then the OEM must do a (warm) restart to do the registry replacement.
This manner of registry persistence is easy to implement. However, because this manner of registry persistence requires a double boot to restore the registry after a device is powered off, it is relatively slow. This method that uses the RegCopyFile mechanism and the RegRestoreFile mechanism is better suited to providing last-known-good backup to protect against errors than it is to providing registry persistence.
With Windows CE 2.10, support is added for a new registry persistence mechanism. An OEM can implement the
WriteRegistryToOEM function and
ReadRegistryFromOEM function in their OEM adaptation layer (OAL). These functions, if implemented, are called by the registry code to save and to restore the data. When the RegFlushKey API is called, the operating system (OS) makes a series of calls to
WriteRegistryToOEM to pass the whole registry to the OEM, who stores the data on any persistent media. Then, when the system boots, the OS makes another series of calls to
ReadRegistryFromOEM to receive the data from wherever the OEM stored the data. 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 the file system calls can be used during
WriteRegistryToOEM, the block and the file system drivers must be read from external media and are not started until after the registry is initialized. Implementation of
ReadRegistryFromOEM is difficult. Code that is read from the persistent media must be added to the OAL. However, this mechanism has the benefit of requiring only a single boot to restore the registry. This is as opposed to the double boot the RegCopyFile mechanism and the RegRestoreFile mechanism both need.
These pairs of APIs cannot be intermixed:
- RegCopyFile and RegRestoreFile
- WriteRegistryToOEM and ReadRegistryFromOEM
The file produced by RegCopyFile is not the same as that produced by
WriteRegistryToOEM.
To address the performance problems and the implementation difficulties of these mechanisms, the Windows CE .NET 4.0 release includes a new type of registry that is named the hive-based registry. The hive-based registry maintains all of its data in files that can be stored on any file system and that can be stored on any media. Therefore, there is no extra work that you must do to persist data on the hive-based registry. Because Windows CE .NET provides the RAM-based registry as an optional component, the persistence mechanisms that are described in this article are still supported on the RAM-based registry. However, the hive-based registry provides a persistence mechanism that is more efficient and that requires no code development by the OEM.