• last updated 3 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[USETUP]: Fix the keyboard selection in the list of OS installations that can be updated.
[USETUP]: NT RTL thread functions use 'NULL' (instead of 'INVALID_HANDLE_VALUE' which is a Win32 thing) for thread handles that are "invalid" / uninitialized.
[USETUP][SETUPLIB]: Code refactoring:

- Move several global setup variables into a structure "USETUP_DATA", similar to the syssetup structure "SETUPDATA"

(or the WIP 1st-stage installer structure of the same name), so that these variables can be set easily by different helper setup functions;

- Move CheckUnattendedSetup() and GetSourcePaths() to setuplib and make CheckUnattendedSetup() use the USETUP_DATA structure;

- Add a LoadSetupInf() function that loads the txtsetup.sif file (factoring out the corresponding code in usetup);

- Add a InstallSetupInfFile() function (that I'll certainly rename later on) whose purpose is to create a valid "$winnt$.inf" setup installation file

in the ReactOS\system32 directory, which should help the 2nd-stage installer to correctly retrieve the source installation media we used during 1st-stage,

and contain the unattended setup lines copied from unattend.inf. This is done in a Windows-compatible way.

- Add the lib/infsupp.c and lib/setuplib.c to compilation.

  1. … 3 more files in changeset.
[USETUP]: Minor code formatting only.
[USETUP]: Sprinkle some INF_FreeData() calls to balance the INF_GetData() / INF_GetDataField() calls. They currently do nothing, since the getter functions don't actually capture (copy) the strings but merely return pointers to read-only strings. But the calls are placed here for consistency, because if one day the getters implementation is changed to capture the strings, then it would now be needed to free the allocated buffers.

In addition, fix a buggy call to INF_GetData() -- should be instead INF_GetDataField() -- in AddSectionToCopyQueue().

  1. … 2 more files in changeset.
[USETUP]: Comment out SetupQueueCopyWNew() declaration which is not used at all. Remove unnecessary casts in the INF_OpenBufferedFileA() call.
  1. … 1 more file in changeset.
[SETUPLIB]: Introduce defines for size units.

[USETUP]: Use them in the code.

  1. … 2 more files in changeset.
[USETUP]: Moving around some code:

- As GetSourcePaths() is used once in usetup to initialize global UNICODE_STRING path strings once, move it out of drivesup.c and put it in usetup.c. Then remove drivesup.c : 1 file less!

- Move some INF file prototype declarations out of usetup.h and inside inffile.h where they should better be, as inffile.h and .c is the glue code for the INF library, defining similar functions as the ones in setupapi.dll.

- I rename our local SetupOpenInfFileW into SetupOpenInfFileExW because the latter one takes an extra user-provided LCID parameter, and this is this one that we use in usetup.

- Make UNICODE_STRING SourcePath; visible only inside usetup.c (not used elsewhere).

- Implement installation path validity check in case we are either in repair/update, or unattended setup mode. If the path is detected as invalid, then we fall back into manual path specification (for now...; note that we could instead fail the installation too).

  1. … 6 more files in changeset.
[BOOTDATA]: Experiment with registry upgrade.

[USETUP]: Fix the name of the txtsetup.sif section to look for when performing a registry upgrade.

  1. … 1 more file in changeset.
[USETUP]: Experiment more with updating/repairing the registry.

Currently partly blocked by CORE-13448.

  1. … 2 more files in changeset.
[USETUP]: Mark some variables as 'static'.
[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).

  1. … 2 more files in changeset.
[USETUP]: Reshuffle a bit the main-function of USetup.
[USETUP]: The 'DestinationDriveLetter' variable (that is just used for SetDefaultPagefile()...) just needs to be initialized at one place only.
[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.

  1. … 4 more files in changeset.
[USETUP]: Diverse fixes:

- Convert almost all swprintf into StringCchPrintfW, and wcscpy into StringCchCopyW;

- Explicitly add a trailing path separator to the "\Device\HarddiskX\PartitionY(\)" paths when they refer to FS directories (and not to partition objects);

- Remove useless (and half-buggy) "Remove trailing backslash" code;

With that, it is possible to install ReactOS in e.g. C:\ReactOS (as usual), C:\ReactOS\dir1\dir2 (as many dirs as you wish), and also in C:\ (yes yes!).

But in that latter case, a strange bug related to the registry arises...

Additionally:

- Adjust some comments;

- Add some debugging DPRINTs;

- The SetInstallPathValue() is part of the big hack I've mentioned in r74709;

  1. … 1 more file in changeset.
[USETUP]: Refactor the DoesFileExist() function so that it now looks closer to DoesPathExist() and use it almost everywhere. Adjust also its callers, adjust OpenAndMapFile() parameters.

Related to that, simplify IsValidNTOSInstallation() parameters & introduce a IsValidNTOSInstallation_UStr that does the same but takes a UNICODE_STRING instead. Simplify CheckForValidPEAndVendor().

Now only exactly 5 calls use the "old" 'DoesFileExist' syntax, using a temporarily auxiliary function "DoesFileExist_2"...

  1. … 4 more files in changeset.
[USETUP]: Use the newly-introduced CombinePaths and ConcatPaths functions.

Fix also few comments, and place some UNICODE_NULLs here & there.

  1. … 5 more files in changeset.
[USETUP]: Addendum to r74614: Code adaptations for the "STRING_HDDINFOUNKx" string labels renaming. The extra slot added to some of the strings is to indicate whether the disk is MBR or GPT.

As attentive readers will notice, the code that "determines" whether the disk is either MBR or GPT is of course wrong: it's just a temporary placeholder code that should currently just show "MBR".

Having the NoMbr flag mostly signifies that the disk is uninitialized. A GPT disk also has a MBR but it's for "backcompatibility" / "protective" reasons (so that MBR-only tools would see the disk as just a big 1-partitioned only disk with which they could barely do anything). A real involved test for the nature of the disk should involve calling the correct IOCTLs in the disk detection code in partlist.c . This is for the future (and when ReactOS will better support GPT disks).

  1. … 1 more file in changeset.
[USETUP]: Implement most of the "upgrade" page (where existing NTOS installations are listed).

- Modify a bit the page flow so that the upgrade page is inserted before the Device-settings page, and after the Install-Intro page.

- Insert some extra 'RepairUpdateFlag' checks in SelectPartitionPage() and InstallDirectoryPage() to take specific actions in case the flag is TRUE.

- As overviewed in r74573, move 'TempPartition' and 'FormatState' back to USETUP.

  1. … 3 more files in changeset.
[USETUP]: Massage the USETUP interface code:

- The "intro" page is renamed into the "Welcome" page, because its corresponding resource indeed is the welcome screen;

- Because the "setup start" page can only be displayed once, move it out of the while-loop, and use its result as the initial value of the 'Page' variable.

- Remove unneeded _PAGE_NUMBER_DEFINED guards;

- Add a DPRINT in the RepairUpdateFlag case of RegistryPage() (because we don't implement yet a correct upgrading or repairing of the registry.

- Use the previously-introduced 'PreparePartitionForFormatting()' function; set the FormatState of the newly-formatted partition to Formatted.

- In InstallIntroPage(), display the page itself only if needed (i.e. after all the validation checks & repair/update or unattended checks are done). Similar modifications are done also in DeviceSettingsPage(), SelectPartitionPage()

- Remove the hackish call to CreateFileSystemList() in SelectFileSystemPage().

- Turn both CheckUnattendedSetup() and UpdateKBLayout() into static functions.

- Put large "case"-blocks into brackets.

- Fix the code of ScsiControllerPage() so that it can be compiled if needed, and add a dummy OemDriverPage().

  1. … 1 more file in changeset.
[USETUP]: Introduce "setuplib".

- Add a "setuplib" library (not yet complete), whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer.

- Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib.

- Move SetMountedDeviceValue into the PartList module.

- Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c).

* The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes...

It also manages the partition filesystem recognition, using OS routines.

* The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...).

- Adapt the calling code to these changes.

- Remove some "host" code that was dating back from the dark old times.

  1. … 30 more files in changeset.
[USETUP]: Similarly to what was done for GenLists, factor out the UI code from the partition list code. This will allow to reuse it for the 1st-stage GUI setup too, while using another UI representation.

- Add also two partition iterator functions: GetNextPartition and GetPrevPartition.

  1. … 2 more files in changeset.
[USETUP]: Factor out the UI-specific code from the GenList code, and wrap it inside a GENERIC_LIST_UI structure.

The aim here is to decouple the UI-specific code from code that can be used by both the text-mode USETUP and a future 1st-stage GUI setup.

Indeed, the GenLists can actually be used in the 1st-stage GUI; and their contents be displayed inside ListBoxes/ListViews... (this is just one example amongst others).

Additionally (in usetup.c):

- Make both FormatPartitionPage and CheckFileSystemPage return PAGE_NUMBERs.

- Improve a couple of comments.

  1. … 2 more files in changeset.
[USETUP]: Further improvements:

- Comment more some of the fields in the PARTENTRY, DISKETNRY and PARTLIST structures;

- Remove the redundant members "SystemDisk", "OriginalSystemDisk" and "TempDisk" in PARTLIST as these can be consistently deduced from the corresponding (Original)(System)(Temp)Partition members

(note that we however keep "CurrentDisk" alongside "CurrentPartition", see the comment in the code why we do it so).

- Adjust the rest of the code to take the removal of the redundant members into account. The 2nd parameter of GetNextUnformattedPartition() and GetNextUncheckedPartition() are now really optional.

- Introduce a SetPartitionType() helper to simplify the code that sets the partition type, which also automatically adjusts other internal variables of said partition in accordance.

- "Mounted" logical drives can have assigned letters too, registered in \DosDevices\.

  1. … 2 more files in changeset.
[USETUP]: Code formatting only.