Condividi tramite

OS updates and the hive-based registry

  • Articolo

Posted by: Sue Loh

 

I attempted to document this behavior in the file that has become https://msdn.microsoft.com/library/en-us/wcedata5/html/wce50conUpgradingtheHiveBasedRegistry.asp. It is not very discoverable information though, I fear. And some of the information in that doc has gotten vague as more hands have crossed over it. I swear there used to be more information there, but it has disappeared into the void. Here I'll attempt to recreate it.

 

The system.hv and user.hv file on your device's persistent store are tied to default.hv and user.hv in ROM. All of these files have an MD5 hash of your "reginit.ini" file from your release directory stored in them. If you build a new image with a new system.hv/user.hv, then the MD5 hash in those files will be different than the hash in the ones on the persistent store. If you download the new image onto a device with persistent registry files that went along with a previous image, the persistent files will be deleted during boot. They MUST be deleted, really, because the persistent files contain many cross-links to the data inside the ROM files, which will be invalid if you change the ROM files. The registry would be severely broken. We don't delete the files just to be annoying, but because we have no choice.

 

You might find that on day-to-day rebuilds, you can keep your registry. That happens if you haven't changed any of the .reg files that go into your image, because reginit.ini would still be the same, so even if you rebuild new default.hv/user.hv files for ROM, they have the same hash stored inside them and the persistent files can still work. But as soon as you modify a .reg file, even just to add whitespace or comments, your persistent files will be wiped.

 

You actually have two options, if you need to update the image without losing the persistent registry.

  1. Probably your best option for your update is to keep the same system.hv/user.hv in ROM, and store any registry changes that go with the update in a separate file of your own. Then you'd have to write a program to import those changes to the registry during the update. You can keep the same file if you don't change .reg files at all -- but chances are, as part of your own work, you may have already changed them and have no hope to recover the original files. What you can do instead is get the default.hv/user.hv from the original ROM, and swap them into your new image via makeimg tricks like writing your own preromimage.bat.
    • (Sigh) I just went looking for documentation explaining that batch file, and it is lacking -- suffice to say, there are a few batch files that the build system looks for during makeimg, to let you write your own scripts to affect the image at different points during the image building process. preromimage.bat runs at about the last step of the image-building process: after the registry has been built but before everything has been built into the image. If you write a preromimage.bat and set up your system to copy it into your release directory, then you can use preromimage.bat to do things like copy previously-saved default.hv/user.hv into your release directory, so that those go into the image instead of the ones that are built from your own .reg files. I don't know what other .bat file call-outs there might be, but I think there might be preregcomp.bat, postregcomp.bat, prefmerge.bat, postfmerge.bat. Look here for a little more info.
    • This option means you'd probably have to build some tool to parse your reginit.ini and pull out the things that are different from what is in the default.hv/user.hv that you'd be putting into ROM. We don't have anything to help you do that. :-( Nor do we have anything to help you import those differences to the persistent registry during the update.
  2. The alternative is to enumerate the entire registry to some file of your own before the update, then do the update (which would give you a completely new registry), then import the settings from the file you exported after the update. The tricky thing there is to know what settings NOT to write -- since your update might have changed some settings.

Neither option is great, I know.  The image update solution that is built into Windows Mobile 5.0 and that will possibly ** be available in future embedded releases deals with this problem basically by putting an empty default.hv/user.hv in ROM from the start, and importing everything during the first boot after an update.

 

** I have to say "possibly" because I can never promise what is going to be in future releases. I cannot guarantee anything.

Comments

  • Anonymous
    September 22, 2005

    > The image update solution that
    > is built into Windows Mobile 5.0

    Hello Sue, and thanks for another of your great articles :)

    I represent an OEM and we have a rather painful experience in how to persist registry during OS upgrades, it feels like re-inventing the wheel.

    Can you give any further information about how this works for WM5.0? I'm curious to know, because I want to see if it's something I can mimic for our Windows CE platform.
  • Anonymous
    September 22, 2005
    The Image Update technology in Windows Mobile 5.0 includes a mechansim for updating the ROM registry hives without destroying the contents of the "RAM" hives on persistent storage. This registry update consists of 3 basic steps:

    1) Export the existing RAM hive contents to a text file. This would be dificult to mimic programatically since there is no way for an application to enumerate only the RAM hives without enumerating the ROM hives, as well.

    2) Rebuild the ROM hives based on .rgu registry files (just Unicode .reg files, used by WM in the past). This is essentially equivalent to just replacing the .hv files in ROM, or updating to a new nk.bin.

    3) Import the text file exported in step #1 into new RAM hives. This could be done with a simple application that runs on early boot after an update.

    Again, it would be difficult to mimic this process exactly because there is no way to perform a RAM-hive-only export in step #1 (especially if you want to somehow export deleted keys and values, which can't be enumerated at all).

    Regards,
    Andrew
  • Anonymous
    September 22, 2005
    Here is what I would suggest:

    Release #1. The stuff that goes into this release is what you'll have burned into ROM forever. Save off a copy of reginit.ini, default.hv and user.hv.

    Releases after that: Make a tool that parses reginit.ini, builds up an internal "tree" representation of the registry, removing duplicates and such like that so that you end up with what would really go into the registry. Have it sort keys and values into alphabetical order. Output the results to a new text file. Run this on your OLD reginit.ini and your NEW reginit.ini -- now you can do an easy diff. Use this diff to produce a text file that you will include with your update. [The diff may involve key/value deletions in addition to key/value creation & changes.] Then write device-side code to import this diff at update time.

    I've wanted to write some kind of power tool to do this stuff in the past, but never found the time/energy to.

    In the meantime, some enterpreneurial person out there could develop this and sell it... Or a less capitalistic person might give it away. :-)

    Sue
  • Anonymous
    June 15, 2009
    PingBack from http://mydebtconsolidator.info/story.php?id=15687