[USETUP]: Implement work-in-progress code that, when upgrading an existing ReactOS installation, verifies whether the (existing) system registry hives are valid (by loading & unloading them, this allows using the built-in repair functionality if needed), or not. If a given hive cannot be repaired successfully, it is backed up (with a '.brk' extension, "brk" as "broken"), then is marked up for recreation. When all hives have been checked, if there are any hive that needs to be recreated, we recreate its hive file, mount it, but we do *NOT* mount the other valid existing hives for update. We create instead dummy registry hives so that we can actually use, as the update code, the same one as the one used when fully creating the registry hives for a clean installation (of course, this choice can be improved later on). The update code (i.e. the same as the registry clean-install one) then adds the registry keys & values, either putting them in the dummy registry hives (the ones that we don't want to recreate) or in the registry hive that is recreated. At the end, the (re)created registry hives are flushed back to disk, and a copy of them (under a '.sav' extension) are created, so that they can be used for restoration purposes if 2nd-stage (and up) goes berserk.
Extra fixes: - Use the correct structure member field when initializing the 'InstallDir' variable, when performing an upgrade. - CreateNestedKey() should be better analysed to see whether it correctly creates the full registry path compatible with volatile/non-volatile keys (under inspection).
[USETUP]: Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality). The rationale is as follows. We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive, similarly to regular ROS running instances (livecd, regular installation...). The ReactOS-specific SetInstallPathValue() hack, introduced in r3794 and r3795, is removed. This hack told the kernel that, during the setup, it should "switch" the used registry hives and instead use the ones of the ROS installation being prepared. This was really hackish because this means, mixing between registry settings used only for the setup running instance, that could use different registry settings than the ones that should be set for the ROS installation being actually performed. Also, note that in the case of a 1st-stage GUI setup, consisting in running the LiveCD + the GUI setup program, this situation would be untenable. Note also that for people willing to use the Setup*** functions exported by setupapi.dll to parse the registry INF files to initialize the registry of the ROS installation being prepared, this would be impossible either. Hence the need to have offline registry modification functionality.