- Use adequate access flag when opening symbolic links.
- Simplify the prototype of UpdateRegistry() since now both Setup INF
handle and settings lists are inside the USETUP_DATA structure.
This means, call in the correct order the user callback with the correct
parameters (in particular the correct paths for file copy operations),
and check also for the callback returned value to know whether or not to
continue the file operations.
This allows using some of the SetupApi.dll functions when SETUPLIB is
used in the (Win32) GUI 1st-stage installer "REACTOS", while using the
custom implemented NT-aware functions in "USETUP".
- Add support for delete and move/rename operations, which are needed
for implementing ReactOS upgrading support.
- Use cabinet contexts.
- Use standard LIST_ENTRY structures for implementing the lists.
- Move the path-building hack code in SetupCommitFileQueueW() that had
been introduced in r66604 (97bb83f) out of the file-queues code.
- Make the function prototypes compatible with win32's setupapi functions.
- Fix the format of the data passed to the custom notification handler.
- Adjust the file-copy callback to correctly use its arguments (setupapi-compatible).
- Move a great deal of global variables into the USETUP_DATA structure
(the SetupInf, the SetupFileQueue, the generic lists...).
- Place the common setup initialization code into an InitializeSetup()
routine, and the cleanup code into FinishSetup().
- Implement the setup-code part support for the TXTSETUP.SIF setup
source path override variables "SetupSourceDevice" and "SetupSourcePath"
(see CORE-9023); support for them in SETUPLDR will be added later.
- It can therefore be also used by the 1st-stage GUI setup.
- Rename some function parameters to clarify what they should be.
Based on:
svn path=/branches/setup_improvements/; revision=75750
[USETUP] Improve usage of ERROR_TXTSETUP_SECTION and ERROR_CABINET_SECTION error codes, correctly display associated error message, and remove a deprecated string.
- Apart from allowing a UI cache variable that may be used when
displaying GENERIC_LIST_ENTRY-ies, do not store any display strings
associated to these list entries. They should be instead computed only
when initializing a list UI (or a combo-box or list control if the
code is used in Win32 environment).
For this matter a callback is provided to InitGenericListUi() that
does the job of computing the displayed string corresponding to a
given GENERIC_LIST_ENTRY.
- Simplify the calls to InitGenericListUi(), and refactor the
RestoreGenericListUiState() function.
- Use for-loops for iterating over GENERIC_LIST items.
- Adapt the storage data format for lists of settings items.
- The txtsetup.sif INF format specified in LoadSetupInf() should not be
INF_STYLE_WIN4 (to be investigated...).
- Use OBJ_CASE_INSENSITIVE when initializing object attributes
(no actual reason why to keep case sensitivity there).
- Check the success of a RtlStringCchPrintfW call in EnumerateReactOSEntries().
- Explicitly check for returned STATUS_NOT_SUPPORTED from ChkdskPartition()
or FormatPartition(), and display an appropriate error message.
- Remove some left-over comments but also explain why I kept some
commented code (mainly for future reference).
Only convert to ANSI when needed (e.g. in the display code for usetup).
The 1st-stage GUI setup will however use the UNICODE strings directly.
svn path=/branches/setup_improvements/; revision=75753
[SETUPLIB] Copy the mui* files from usetup into the setuplib for later usage, and add mui.c to build.
svn path=/branches/setup_improvements/; revision=75711
[SETUPLIB][USETUP] Start massaging the MUI files and split up what concerns only the usetup "resources",
and what concerns general language parameters (in the setuplib).
It may be interesting to retrieve the language parameters
from INF file (e.g. intl.inf) (suggested by Giannis).
svn path=/branches/setup_improvements/; revision=75715
[SETUPLIB] Add the necessary headers to mui.c to be able to compile.
[USETUP] Comment out the languages that don't have any resources.
svn path=/branches/setup_improvements/; revision=75716
[SETUPLIB][USETUP] Adjust MUI and settings code.
- Re-enable settings code concerning language, keyboards & layout
in the setuplib, and remove the old code in usetup.
- Remove useless code in setuplib's mui.c.
- Rename usetup's MUI "LanguageList" into "ResourceList" so as to
avoid colliding with the "LanguageList" of setuplib.
- Add the magic CMakeLists line "add_definitions(${I18N_DEFS})" that
I forgot previously, that caused the "LanguageList" of setuplib to be empty!
The code compiles and works during my tests.
svn path=/branches/setup_improvements/; revision=75717
[SETUPLIB] Change some string pointer types & function prototypes so that the usetup-specific
"SelectedLanguageId" variable is not used in the library.
svn path=/branches/setup_improvements/; revision=75719
[SETUPLIB] Change some function prototypes so that the usetup-specific "SelectedLanguageId" variable is not used in the library.
Also, make AddEntriesFromInfSection(), DefaultProcessEntry() and the typedef PPROCESS_ENTRY_ROUTINE private again.
svn path=/branches/setup_improvements/; revision=75720
svn path=/branches/setup_improvements/; revision=75724
[USETUP] Code adaptations.
- Transform some do{}while() loops into while(){} ones, since the lists on which we work may only contain one single {NULL} element.
- Modify MUIGetOEMCodePage() call after r75719.
- Use PCWSTR where needed.
svn path=/branches/setup_improvements/; revision=75722
[USETUP] Adjust some MUI & settings calls, following the commits r75719, r75720 and r75721.
svn path=/branches/setup_improvements/; revision=75723
[INPUT.CPL] Adjust inclusion of "muifonts.h" (commit 3dbd44f) due to changes introduced in r75711 and r75715.
Move the bootsup.c code into the setuplib, as the code is generic
enough to be used by both USETUP and the 1st-stage GUI installer.
svn path=/branches/setup_improvements/; revision=75674
- 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 probably 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.
svn path=/branches/setup_improvements/; revision=75518
[USETUP] Close the txtsetup.sif file at the end of the operations.
svn path=/branches/setup_improvements/; revision=75539
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 so that strings are captured, it would
then be needed to free the allocated buffers.
In addition, fix a buggy call to INF_GetData() -- should be instead
INF_GetDataField() -- in AddSectionToCopyQueue().
svn path=/branches/setup_improvements/; revision=75516
- 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).
svn path=/branches/setup_improvements/; revision=75246
- 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.
svn path=/branches/setup_improvements/; revision=74576
svn path=/branches/setup_improvements/; revision=75525
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).
svn path=/branches/setup_improvements/; revision=75010
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 a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "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.
svn path=/branches/setup_improvements/; revision=74766
- Also, reserve a new field to display whether the disk is MBR or GPT-initialized.
- Adjust the code that used the "STRING_HDDINFOUNKx" string labels.
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 just temporary: it's just a 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).
svn path=/branches/setup_improvements/; revision=74614
svn path=/branches/setup_improvements/; revision=74615
- 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).
- 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()
- Turn both CheckUnattendedSetup() and UpdateKBLayout() into static functions.
- Fix the code of ScsiControllerPage() so that it can be compiled if needed, and add a dummy OemDriverPage().
svn path=/branches/setup_improvements/; revision=74575
- 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 f51faa4a (r74709).
svn path=/branches/setup_improvements/; revision=74717
- Add the MUI ID resource.
- Implement the shutdown timeout progress bar function and the TimeOut string handler.
- Add the resource string to other resource languages.
- 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"...
svn path=/branches/setup_improvements/; revision=74641
This allows building concatenated paths with an arbitrary number of separated components.
- Use the newly-introduced CombinePaths() and ConcatPaths() functions.
- Fix also few comments, and place some UNICODE_NULLs here & there.
svn path=/branches/setup_improvements/; revision=74637
svn path=/branches/setup_improvements/; revision=74640
- Use the previously-introduced 'PreparePartitionForFormatting()' function; set the FormatState of the newly-formatted partition to Formatted.
- Remove the hackish call to CreateFileSystemList() in SelectFileSystemPage().
- Move 'TempPartition' and 'FormatState' back to USETUP.
- Put large "case"-blocks into brackets.
svn path=/branches/setup_improvements/; revision=74575
svn path=/branches/setup_improvements/; revision=74576
- Create the beginnings of a "setuplib" library, 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.
svn path=/branches/setup_improvements/; revision=74570
svn path=/branches/setup_improvements/; revision=74659
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.
svn path=/branches/setup_improvements/; revision=74554
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.
svn path=/branches/setup_improvements/; revision=74553
- Document 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() is 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\.
svn path=/branches/setup_improvements/; revision=74532
