Pressing Shift-F10 to open cmd.exe when the setup program runs from
a different current directory than System32, now works correctly.
Use the 2nd CreateProcessW() `lpCommandLine` parameter, instead of the
1st parameter `lpApplicationName`, so as to use default path search.
The command-line buffer given to the 2nd-parameter can be temporarily
modified by CreateProcessW(), thus use an on-stack buffer.
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw#parameters
They are redundant when these are already present in the given module's
root resource file, from which the language-specific resource files are
being included.
Addendum to 0.4.16-dev-323-g c212c184f3 (#7352).
In the usage help message one line started with '\pentru', but it should have been '\tpentru'.
Fixes GCC compiler error:
base/applications/mscutils/eventvwr/lang/ro-RO.rc:177: unrecognized escape sequence
Co-authored-by: George Bișoc <george.bisoc@reactos.org>
CORE-13525
Notes:
- Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI".
- The two InitializeSetup() phases have been collapsed to make the initialization simpler.
Average reductions (percentages; see PR #7523 for actual numbers):
x86 Debug builds:
reactos.exe: 35.1%
smss.exe : 39.8%
Total (including setuplib.dll): 17.9%
x86 Release builds:
reactos.exe: 22.3%
smss.exe : 25.0%
Total (including setuplib.dll): 10.6%
x64 Debug builds:
reactos.exe: 40.6%
smss.exe : 41.6%
Total (including setuplib.dll): 20.0%
x64 Release builds:
reactos.exe: 22.8%
smss.exe : 22.3%
Total (including setuplib.dll): 10.1%
Improves detection of Explorer being the default shell.
- Check the "Software\Microsoft\Windows NT\CurrentVersion\Winlogon" key to see if Explorer is the default shell.
- Use this check to determine whether to start the desktop and taskbar or only open a file browser window.
JIRA issue CORE-19887
Fixes previous attempt at commit 0ca4e6dcf, which was reverted by commit
bbdcc14b1 because the partitioning checks mistook unpartitioned disks as
GPT.
Addendum to commit 99f0937fd.
The partition-creation checks are unified for these partitions into one
single function. To prepare for GPT support, the specifics are put into
a separate MBRPartitionCreateChecks() helper, called for MBR disks by the
upper-level function. GPT disks will have a similar helper in the future.
Addendum to commmit 99f0937fd.
The partition-creation checks are unified for these partitions into one
single function. To prepare for GPT support, the specifics are put into
a separate MBRPartitionCreateChecks() helper, called for MBR disks by the
upper-level function. GPT disks will have a similar helper in the future.
- no functional change intended
- shrinks the rc files sizes and shrinks the binary size of taskmgr:
RosBEWin2.2.2 GCC8.4.0dbg taskmgr.exe from 696.320 -> 678.912 bytes ==> 17.408 bytes saved in the binary
- does also slightly beautify those lines when displaying them in the reshacker
JIRA issue: none
Refine the algorithm introduced in commit c560342f08 (r75667, r75676),
whereby the installation source path is based on the full image file path
of the installer program, and of the \SystemRoot symlink.
Also reverts commit 6f389a35db "Add a workaround for installing from USB drives"
CORE-17818
+ SAL2-annotate and add Doxygen comments.
----
In case the \SystemRoot full path prefixes the image file path,
use the resolved \SystemRoot as the installation source path.
Otherwise, use the image file path.
The \SystemRoot symlink target resolution needs full path reparsing,
because it can reference other symlinks. This is what happens, for
example when booting the installation from a removable hard-disk.
We can have:
\SystemRoot ---> \Device\Harddisk1\Partition1\ReactOS
and: \Device\Harddisk1\Partition1 ---> \Device\HarddiskVolume2
etc.
and we wish to resolve \SystemRoot to: \Device\HarddiskVolume2\ReactOS
instead of keeping the former version (using Harddisk1\Partition1).
We then verify whether it prefixes the image file path, which is
a fully reparsed path.
CORE-13525
This is done so that the caller doesn't need to know details
about particular architecture specifics, like VBR, MBR etc.
Extra checks and specific handling is also performed for supporting
bootloader installation on removable media:
- verify whether the media is a floppy or some other removable media,
- depending on which, a suitable file system is chosen,
- and if the media is not a floppy, do the supplemental partition
verifications to determine whether the media is a "super-floppy"
(in the partitioning sense).
