| Author |
Topic |
|
|
ctacke
877 Posts |
 Posted - 08 Jul 2004 : 14:58:57
|
Persistent Registries
All current ADS devices running CE 4.x have the ability to persist their registry. There are two general types of persistent registry: RAM-based Heap File or Hive based.
A RAM-based registry keeps all registry modification data in RAM. If power is lost or the device is hard-reset, all data modifications made to the registry are lost. To persist the object store information, an application must call the RegFlushKey API. The call is a blocking call and can take a couple seconds to complete since it persists the entire heap file, but the registry read/write APIs are quite performant because they are going to RAM.
More detail can be found in this MSDN topic. ADS used the second mechanism described in the topic for persisting RAM-based registries.
A Hive Based registry maintains the flash-persisted differential file with each registry write call. This means that your application never needs to call RegFlushKey to persist and the registry will always be current even if power is lost. The penalty is that since flash access is significantly slower than RAM access the registry read/write API calls will be much slower with a Hive-based system.
To erase either type of persistent registry, you can use the ADS Persistent Registry Control Panel applet or the EraseRegBackup.exe application found in the device's \Windows folder.
More detail can be found in this MSDN topic.
For more information on how the persistent registry is loaded at boot time, see Topic 1552. |
|
|
3963
85 Posts |
Posted - 18 Nov 2005 : 17:22:54
|
| So, when converting from my current RAM-based app that uses the RegFlushKey API to the new Hive-Based image, do I need to 'search & destroy' all my RegFlushKey calls? IIRC, the RegFlushKey API is OEM-dependent -- is it no-op'd in the Hive-based images or does it still flush (and, hence, take a second or two)? |
 |
|
|
ctacke
877 Posts |
Posted - 18 Nov 2005 : 17:54:55
|
| Nope, on Hive based it still flushes and is required if you want the changes to persist. The main difference is it now flushes to a hive file (located in \FlashFX Disk\Documents and Settings) so flash access is controlled by the filesystem driver, and therefore is safer. It only saves the alterations, so it's typically faster that the older RAM flush. |
|
|
|
rsrumrill
20 Posts |
Posted - 21 Nov 2005 : 14:34:53
|
| I am using build 4.20.32 with the new hive-based registry. What's the secret to persisting some of the control panel settings? Specifically, the regional settings will not persist unless I make a call to RegFlushKeys. I thought that a primary advantage of going to hive-based was the the elimination of this call. |
|
|
|
ctacke
877 Posts |
Posted - 21 Nov 2005 : 15:02:53
|
No, a Hive-based registry does not eliminate the need for a call to RegFlushKey. The primary difference between the object-store and Hive based registry systems is where and how the registry data is saved.
Background
With a RAM-based registry, the OEM decides how and where to save the data. ADS made the decision to save that data in a flash region after the ADSLOAD.* files and before the images. The issue with that is that the routines to write to that area were not synchronized with the file system and it allowed to potential for two threads to try to access Flash at the same time. This can have a very negative impact on the system, leading to flash corruption.
A Hive based registry stores the information through the File System driver, the location again is determined by the OEM. ADS chose \FlashFX Disk\Documents and Settings. The advantage is that now all access to flash are handled by one driver, which can effectively serialize access to the hardware resource and protect against request collisions. To make it even more robust, we added the Reliance driver, which makes the file system transacional, so an interruption of power during a write no longer has potential catastrophic implications either.
Hive-based images can be set to auto-persist with a certain periodicity. We tried doing that but found a negative impact on system performance and since an application developer knows better than we do on when data should be persisted, we chose to leave that decision in their hands.
One small difference is that with Hive-based systems, the OS *will* auto-persist the registry when the device goes into suspend mode. That is the only situation that the OS will automatically call RegFlushKey. |
|
|
| |
Topic |
|
|
|
All Forums
Microsoft Windows CE
Persistent Registries
Forum Locked
Topic Locked
Send Topic to a Friend
Printer Friendly