Remove the commented-out IsValidPath() in that file, and remove
as well the temporary prototypes in regutil.c .
svn path=/branches/setup_improvements/; revision=75249
Split the registry helper code into registry utility functions
(create/mount/unmount/verify hives) and registry creation code
(the rest: initializing the system hives) and move it in the
setup library.
svn path=/branches/setup_improvements/; revision=75247
[USETUP][SETUPLIB] Improve how the Setup* INF APIs are interfaced in the code.
Define prototypes compatible (including their calling convention)
with the ones defined by setupapi (.h/.dll) so that it can be possible
to either use an internal implementation of these functions (via the
INFLIB library) as currently being done, or using imported setupapi
functions, as would be done by the future 1st-stage GUI installer.
[SETUPLIB] Cleanup the registry.c file and use the infsupp.h header.
svn path=/branches/setup_improvements/; revision=75345
svn path=/branches/setup_improvements/; revision=75346
[USETUP][SETUPLIB] Move some INF-related code from usetup to the setuplib.
- Move the generic INF_GetDataField() and INF_GetData() helpers to
setuplib, and rework them a bit so that they explicitly call setupapi
functions (or implementations thereof when being used in usetup);
- Rework the headers in accordance;
- Fix compilation in lib/registry.c .
- Fix compilation when these headers are used withing usetup (who
doesn't use setupapi.dll) and "reactos" (the 1st-stage GUI installer
that uses setupapi.dll).
svn path=/branches/setup_improvements/; revision=75515
svn path=/branches/setup_improvements/; revision=75537
svn path=/branches/setup_improvements/; revision=75538
- 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
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.
- Adjust the code that calls SetupCopyFile().
svn path=/branches/setup_improvements/; revision=75008
svn path=/branches/setup_improvements/; revision=75009
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
- Make the strings translatable.
- Include the English translation within the main resource file.
- Use ConResPrintf() and ConResPuts() for resource strings.
Fixes in particular a regression brought by 57402ee (thanks George Bisoc
for having noticed this), where the BTRFS bootsector code could not be
installed anymore.
CORE-15192
- Fix the usage of the BootEntry's "Version" member.
- Don't surround with too many quotation marks the "friendly" boot entry name in AddBootStoreEntry().
svn path=/branches/setup_improvements/; revision=74964
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).
svn path=/branches/setup_improvements/; revision=74954
This concerns 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.
This code is 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 a UNICODE_STRING anymore).
svn path=/branches/setup_improvements/; revision=74943
[SETUPLIB] Make the NTOS_BOOT_ENTRY structure 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 cleanup will follow later.
svn path=/branches/setup_improvements/; revision=74952
- 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
Also, trim any potential trailing path separator from the NT disk partition path before opening the partition object itself for read/write access.
svn path=/branches/setup_improvements/; revision=74715
- Transform TryToStartShell() into a StartProcess() function whose aim
is just to start processes, since there is no extra initialization needed
for starting a shell process.
- Modify StartInstaller() to call StartProcess() for starting the ReactOS GUI
installer found on the installation media, from a path automatically expanded
depending on the ambient CPU architecture.
svn path=/branches/setup_improvements/; revision=75331
- Don't hardcode the installer file name in ExpandInstallerPath() but
provide it from a parameter. Return TRUE/FALSE if the installer file
is/is not found.
- Expand any environment string present in the items command line.
- Enable/disable the menu buttons depending on whether or not an
associated command is present.
- Enable mirroring from resources.
- Flush the new control set after the control set has been created.
- Make sure that we create a new control set only on the first boot after setup.
- Move the control set copy code to a separate function.
- Get rid of the global control set values.
Also comment about the observed behaviour of the returned number of "characters"
returned by the ANSI versions of these APIs (which is tested by advapi32_winetest:service).
[ADVAPI32:SCM] Add a comment concerning wide characters vs. bytes mismatch.
- Encrypt passwords before passing them to the service manager. Right now, we are using a fixed encryption key. This will be fixed later.
- Replace the calls to ZeroMemory which are used to wipe the password buffers by calls to SecureZeroMemory.
This will also fix MS Office 2010 installation, where the installation
expects the NetworkService account profile to be already loaded (this
condition is always verified on Windows since RPCSS and other services
also run under this account).
CORE-14988, CORE-14989
This avoids keeping connections open and reopening them as soon
as the user reopens their session.
This fixes network shared being duplicated each time session
is reopened.
CORE-15012
- 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.
- Simplify the usage of the PUPDATE_PROGRESS callback.
- Add the possibility of specifying an initial non-zero StepCount when
creating the progress-bar (using the -Ex version), so that it can be
initially drawn with the expected initial count.
Of course ProgressSetStepCount() can continue to be used.
Updated the font substitutions to use the new Hebrew glyphs in the updated Tahoma font.
Also added substitution for the Ubuntu font to make the Lautus and Modern themes legible with Hebrew UI elements.
Follow up to PR #789 and #790 ; CORE-14880, CORE-14943
Improve the progress bar functions:
- Add a member in the struct, which will be used as a bar colour parameter for the new CreateProgressBarEx().
- CreateProgressBar() which will now invoke the Ex variant without the additional parameter.
as documented in "Advanced Windows NT" by Jeffrey M. Richter (Microsoft Press),
and in https://is.muni.cz/el/1433/jaro2010/PB167/um/cv5/undocumented_CreateProcess.pdf .
[INCLUDE][SERVICES][WIN32K:NTUSER] Add an undocumented STARTF_INHERITDESKTOP flag
for the STARTUPINFO::dwFlags structure member, whose purpose is to tell Win32k
that the created handles to the window station and desktop to which the
process is connecting to, can be inherited by its child processes.
It is used when starting interactive services.
Observed via API monitoring on Windows 2003.
The PROCESS_DEVICEMAP_INFORMATION union has 2 fields, one is a handle, the other one is a structure of 36 bytes (independent of architecture). The handle forces 64 bit alignment on 64 bit builds, making the structure 4 bytes bigger than on 32 bit builds. The site is checked in NtQueryInformationProcess (case ProcessDeviceMap). The expected size on x64 is the size of the Query structure without alignment. autocheck correctly passes the site of the Query union member, while smss passes the full size of PROCESS_DEVICEMAP_INFORMATION. Packing the structure is not an option, since it is defined in public headers without packing. Using the original headers sizeof(PROCESS_DEVICEMAP_INFORMATION) is 0x28, sizeof(PROCESS_DEVICEMAP_INFORMATION::Query) is 0x24.
Fix vertical alignment and Aspect penalty; improve font penalty system; fixes for Wine tests.
This is an update of #706. See CORE-11536 for more details.
The display of the following programs is fixed:
- Total Commander 8.52 setup: font displayed too large - CORE-11620.
- Effective File Search 6.8.1 german localization text rendering issues - CORE-14378.
- Font garbage in register splash screen in Foxit Reader 7.1.5 - CORE-9767.
- Calipers-1 is not displayed correctly - CORE-14302.
- Some MSI-installers draw their dialogs too large (example: Click-N-Type Virtual Keyboard 3.03.0412) - CORE-13161.
- Irfanview 4.50: font in zoom combobox displayed too large - CORE-14396.
- Rufus: The window and controls are displayed larger than necessary - CORE-14461.
Particular DIR commands like: "DIR .", "DIR .." now work as expected,
and we also correctly fix the behavior for files without extension,
that r38746 (2b06cfc0) originally tried to fix but broke the previous
examples.
Therefore "DIR *." and "DIR noextfile." work too.
Pathological cases like "DIR \...", "DIR \...\.", "DIR ..\...\.." and
the like (and with more than 3 dots) now work as expected.
Adapted from PR #592 by Katayama Hirofumi MZ, but with extended bugfixing.
CORE-13961
- Service bits are set by NetrServerSetServiceBits and can be retrieved by NetrServerGetInfo.
- The real name of function 42 is NetrServerSetServiceBitsEx and the real name of function 47 is NetrDfsSetServerInfo.
