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%
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).
CORE-13525
This greatly helps in reducing code complexity in some areas: code that
previously iterated over all partitions of a given disk, just to find
which ones were partitioned and contained a valid file system, now just
have to iterate over mounted volumes.
See in particular, `lib/utils/osdetect.c` and `lib/fsutil.c` .
- Remove FORMATSTATE "Preformatted" enum value;
- Cleanup osdetect code after introducing Volume support;
- Some simplifications for FormatState.
- Differentiate between 'new' partition and 'new' volume:
* "New" partition: it has been created and added in the cached list,
but not yet actually written into the disk.
* "New" volume: newly-created volume (may be backed by a partition or
not), not yet formatted. May exist on either new, or not new partition,
or elsewhere.
- Cache partition and volume NT device names.
These do not change across repartitioning operations, as long as the
partition or the filesystem volume hasn't been deleted/recreated.
This avoids doing \Device\Harddisk%u\Partition%u sprintf's everytime
we need to retrieve the given partition or volume device name.
When a partition/fileysystem volume is "virtually" created (i.e. in
the partition list, but not yet committed to disk and exposed to the
OS), no device partition number and device name are available yet.
In particular, validate that no manipulation of \Device\HarddiskM\Partition0
(i.e. the whole disk) is being made.
It will be used to determine how the bootloader has to be installed, etc.
Currently hardcoded for XBOX, or rnutime-determined for NEC PC-98 and BIOS-based PC-AT.
More thorough runtime determination will be added in the future.
Reverts the IsValidPath() move done in commit 9c64b57dc.
- Turn IsValidPath() into a IsValidInstallDirectory() helper function
available in the setuplib, so that it can also be used in the GUI setup.
- Introduce a IS_VALID_INSTALL_PATH_CHAR() macro.
The idea is reminiscent of the SetupCommitFileQueue() function:
filesystem volume operations are "queued" and processed via a
"commit queue".
The commit queue uses a user-specified callback, that is used to
interact with the user whenever an operation (filesystem formatting,
checking) is started, ended, or fails, for example by displaying
appropriate UI screens and choices, etc.
The reason is to avoid enforcing the usage of a specific list
container by the users of the setup library. This is a departure
of what I originally thought would be the best, in commits
92692eae3 (r74553), 8f2c4f7a6 (r75700)
This should actually make some parts of the GUI setup code simpler
(e.g. using the win32 comboboxes to store the list contents).
- Move the actual VBR bootcode installation helpers into fsutil.c
(they depend on the selected filesystem).
- Introduce InstallBootCodeToDisk() and InstallBootCodeToFile()
and bootcode.c helpers, in order to replace the several functions
that were duplicating the same code.
This PR enables the developers to include the CJK standard fonts into ReactOS by adding them in Folder modules/optional. This feature is for test purpose only. You may not use the fonts illegally.
The embeddable font files are: mingliu.ttc, simsun.ttc, mssong.ttf, msgothic.ttc, msmincho.ttc, gulim.ttc and batang.ttc.
CORE-9619
- Add also some validation ASSERTs and simplify the code here and there.
- The installation partition is called "InstallPartition", while the
global "CurrentPartition" is the disk region currently selected in
the partition UI list, on which prtitioning operations are effectued.
- Extend CheckActiveSystemPartition() to use an optional alternative
disk or partition in case the actual system partition (present in the
first disk) cannot be used, e.g. because we don't support writes on it.
By default, we still fallback to FAT if nothing asked, or if there
is an invalid input.
0 is FAT, 1 is BtrFS. This can be grown as soon as we add more IFS.
- 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 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".
- 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
[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.
This code is moved ther since it'll be needed for 1st-stage GUI
installer as well.
The code dealing with keyboard layouts is however not moved yet,
since it uses MUI* functions from usetup.
I'll try to think how to include that in setuplib...
svn path=/branches/setup_improvements/; revision=75701
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
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
- Use NT string safe functions.
- Add support for other bootloaders;
- Update a couple of comments;
- Remove deprecated __REACTOS__ #ifdefs.
svn path=/branches/setup_improvements/; revision=74713
- filesup.c's functions ConcatPaths(), Does[Path|File]Exist(), NtPathToDiskPartComponents(), OpenAndMapFile(), UnMapFile();
- Move the inicache library to setuplib as it'll be used for the 1st stage GUI setup too (indeed, there is no good INI file API
under Win32; the Win32 profile "API" is just good enough to manipulate the win16 ini files, and are here anyways for backward
compatibility purposes only);
- Move the OS detector too.
- Remove the duplicated ConcatPaths() code in arcname.c.
svn path=/branches/setup_improvements/; revision=74634
svn path=/branches/setup_improvements/; revision=74638
The NT path resolver allows mapping between an ARC path as specified in freeldr.ini / boot.ini , to its corresponding NT path, if possible.
Currently, only the mapping direction "ARC to NT" is implemented. It will be used wherever such mappings are needed, for example when identifying
the ReactOS / Windows installations from the available freeldr.ini / boot.ini entries (for upgrading / repair purposes).
The resolver supports the usual ARC paths: multi()disk()[r|f]disk()[partition()] ; eisa()disk()[r|f]disk()[partition()] ; multi()disk()cdrom() ;
scsi()disk()[r|f]disk()[partition()] ; scsi()cdrom()fdisk() ; ramdisk(x) ; net(x) (actually reported as "unsupported" since it would map to some
path on some network), and the newly-introduced Win2k signature()disk()rdisk()[partition()].
The code is in work-in-progress status.
Some validation tests, that were used during the implementation of the resolver, have been added.
svn path=/branches/setup_improvements/; revision=74621
svn path=/branches/setup_improvements/; revision=74631
- 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
