• last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[NTOS]: Drastically reduce the hackish function CmpGetRegistryPath() for the text-mode setup case (it should ultimately completely disappear).
[USETUP]: Experiment more with updating/repairing the registry.

Currently partly blocked by CORE-13448.

[USETUP]: Mark some variables as 'static'.
Sync to trunk r75154.
  1. … 1440 more files in changeset.
[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]: Addendum to r75008: Adjust the code that calls SetupCopyFile().
[USETUP]: Introduce SetupDeleteFile() and SetupMoveFile() (in addition to the already-existing SetupCopyFile()) in order to implement moving / renaming existing files.

Will be used soon to make backups of system files, like the registry hive files just freshly created.

- Make the SetupCopyFile() function closer to its win32 counterpart.

[USETUP]: Explicitely use the REG_OPTION_(NON_)VOLATILE flags in NtCreateKey calls.
[USETUP]: Reshuffle a bit the main-function of USetup.
[SETUPLIB][USETUP]: Minor code refactoring, consisting in renaming the "ntos boot loader" stuff into "boot store", since this happens to be functionality that is a bit more general than previously thought.

- Fix the usage of the BootEntry's "Version" member.

- Don't surround with too many quotation marks the "friendly" boot entry name in AddBootStoreEntry().

[USETUP]: As evoked in r74943, adapt the code in bootsup.c to abstract the manipulation of freeldr.ini and boot.ini, and make it use the new features of bldrsup.c committed in r74952.

In particular the helper functions CreateCommonFreeLdrSections() and (Un)protectBootIni() are now removed from there (they are used in bldrsup.c only).

This should pave the way for future integration with other sorts of NT boot loaders (BootMgr and (u)EFI boot loader).

[SETUPLIB]: Adapt the code in osdetect.c to make it use the new features of bldrsup.c committed in r74952.
[SETUPLIB]: Make the NTOS_BOOT_ENTRY structure (that should actually be renamed...) more generic, so that it can wrap around either actual NTOS boot entry options, or FreeLdr-like boot-sector options.

In a sense, the NTOS_BOOT_ENTRY structure now looks much more like the NT structure "BOOT_ENTRY".

- Adapt the code in bldrsup.c to these modifications, and re-enable FreeLdr-like boot-sector-file support code that was commented out.

More code cleaning-up will follow later.

[USETUP]: The 'DestinationDriveLetter' variable (that is just used for SetDefaultPagefile()...) just needs to be initialized at one place only.
[SETUPLIB]: Introduce a lot of (Work in progress) functions to manipulate boot entries from different boot "stores" (so far, only freeldr.ini and to an extent, boot.ini, but planning in the future to add support for registry-oriented BCD as well as possibly direct (u)EFI entries, using the corresponding NT functions).

So far only used in osdetect.c, but will be soon used by usetup's bootsup.c (note that some helper functions: CreateCommonFreeLdrSections() and (Un)protectBootIni() are already taken from it and used in bldrsup.c).

- In EnumerateNTOSBootEntries(), continue enumerating the boot entries until the user callback returns an status code that is not successful.

- Remove some old code from osdetect.c; use directly BootEntry->FriendlyName when building the display names of the available installations, since now BootEntry->FriendlyName is a PCWSTR (and not UNICODE_STRING anymore).

[USETUP]: When installing new FreeLDR entries for recognized DOS/OS-2 boot loaders, use distinct OS section names. Also, add detection for the Dell Real-Mode Kernel OS (DRMK).
  • More
  • CR-98
  • summarized and closed
[BOOTDATA]: This commit is a HACK! Due to strange PnP drivers disconnections(*) happening, in particular those concerning keyboard drivers, thus making 1st-stage unusable, I fork off hivesys.inf into hivesetup.inf, remove the listed PnP devices that seem to cause problems, and use it (instead of hivesys.inf) to build the 1st-stage setup SYSTEM registry hive.

2nd-stage and regular installations on the contrary use the normal hivesys.inf.

(*): disconnections mentioning (this refers to the 'i8042prt.sys' driver):

"Removal vetoed by Root\*PNP0303\0000" [...] "Warning: PnP Start failed (Root\*PNP0303\0000) [Status: 0xc0000010]" and "A reboot is required for the current driver for 'Root\*PNP0303\0000' to be replaced"

[MKHIVE]: Improve dprint output (delimiting where strings start & end: is useful for empty strings).
Sync to trunk r74766.
[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.

[USETUP]: Code formatting, making also the code closer to mkhive's one. Also, definitely remove the SetInstallPathValue() hack.
[FREELDR]: Adjust WinLdrInitSystemHive() and its callers to load either the regular SYSTEM hive, or the SETUPREG.HIV setup system hive, at startup. We now run the 1st-stage setup with a regular system hive, similarly to what's done for the LiveCD, or for a regular ROS installation. The ExpInTextModeSetup hacks I previously removed are indeed now unneeded.
[CMAKE]: Make the mkhive commands actually depend on the generated UTF16 INF files since the latter are those actually used as input to mkhive. Otherwise, the mkhive calls & the UTF16 INF file conversion is not serialized and we can generate "corrupted" hives due to the fact that mkhive is using INF files that are in the process of being (and therefore, only partially) generated.
[NTOS]: Add some dprints in IopLoadServiceModule() and IopOpenRegistryKeyEx() to investigate why these 1st-stage text-mode hacks may, or are (respectively) still needed.
[NTOS]: Cm fixes:

- Rework CmpSetSystemValues() and remove its 1st-stage text-mode setup hack, since I'm going to have a real hive for the 1st-stage either.

- Lock, then unlock the registry in NtInitializeRegistry when initializing the hives & flusher.

- Call CmpInitializeHiveList() (i.e., initialize the other hives like \Software, \User, \.Default) only when we are not in setup-mode.

[NTOS]: Remove other 1st-stage setup hacks that I don't need anymore.
[NTOS]: Remove some hacks that I don't need anymore in the branch (since I'll also use for 1st-stage a real registry hive). This reverts r53255 and r53694, and a hack from r46690.
Sync with trunk r74743.
  1. … 299 more files in changeset.
[FREELDR]: Split the "main" winldr.h header into the one containing global code that actually doesn't really depend on the "windows" NT loader part, and one that actually concerns code just for the NT Loader. The latter goes into ntldr.