[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523)

CORE-13525

Notes:
- Most of the exported functions have been turned from default cdecl to ex

[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523)

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%

show more ...

[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258)

CORE-13525

This greatly helps in reducing code complexity in some areas: code that
previously iterated ove

[SETUPLIB][REACTOS][USETUP] Split FS-volume-specific functionality from partitions (#7258)

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.

show more ...

[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049)

The idea is reminiscent of the SetupCommitFileQueue() function:
filesystem volume operations are "queued" a

[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049)

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.

show more ...

[SETUPLIB] Add NTFS boot support. (#3778)

[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers
so that they wrap the needed init steps for formatting/chkdsk'ing.

These helpers now accept a

[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers
so that they wrap the needed init steps for formatting/chkdsk'ing.

These helpers now accept a PPARTENTRY, together with the usual
formatting/chkdsk parameters. The helpers now determine the actual
NT path to use, and can perform the init steps on the partition
before performing the actual operation.

In particular, FormatPartition() is now made GPT-compliant. The
partition type retrieved by FileSystemToMBRPartitionType() is now
used as a hint for choosing FAT32 over FAT12/16, and only in the
case of a MBR partition that is *NOT* a recognized OEM partition,
it is used for updating the corresponding partition type. (OEM
partitions must retain their original type.)

The OEM partition types we (and NT) can recognize are specified
e.g. in the Microsoft Open-Specification [MS-DMRP] Appendix B
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dmrp/5f5043a3-9e6d-40cc-a05b-1a4a3617df32

Introduce an IsOEMPartition() macro to help checking for these types
(its name is based on the Is***Partition() macros from ntdddisk.h,
and from a dmdskmgr.dll export of similar name).

show more ...

[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions.

[AUTOCHK] Add also support for scanning FATX volumes.

The Format()

[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions.

[AUTOCHK] Add also support for scanning FATX volumes.

The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the
U*.DLL user-mode FS library dlls are different (and have different
prototypes) than the similarly-named functions exported by FMIFS.DLL .

In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()"
in our U*.DLL libraries actually correspond more, from their arguments,
to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their
*Ex() counterparts instead take most of the parameters through a
structure passed by pointer.

On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and
FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these
*Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx()
call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls
U*.DLL!FormatEx() (that we do not implement yet either) !!

To improve that, refactor the calls to these U*.DLL functions so as to
respect the more compatible prototypes: They contain the correct number
of parameters in a compatible order. However, some of the parameters do
not have the same types yet: the strings are kept here in PUNICODE_STRINGS,
while on Windows they are passed via an undocumented DSTRING struct, and
the FMIFS callback is instead a MESSAGE struct/class on Windows.
Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet
not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used
in the corresponding FMIFS.DLL functions.

One thing to notice is that the U*.DLL!Format() (and the Ex) functions
support a BOOLEAN (a flag resp.) for telling that a backwards-compatible
FS version should be used instead of the (default) latest FS version.
This is used e.g. by the FAT FS, where by default FAT32 is selected
(depending also on other constraints like, the disk and the partition
sizes), unless that bit is set in which case, FAT16 (or 12) is used.

show more ...

[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on.

The formatter will select it anyway as soon as the partition size
permits it. We mak

[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on.

The formatter will select it anyway as soon as the partition size
permits it. We make it available internally however so as to "emulate"
FMIFS functionality.

Now rely on the partition filesystem for InstallVBRToPartition() instead
of the unreliable and deprecated partition type.

show more ...

[SETUPLIB] Code re-organization in bootsup.c and fsutil.c.

- Move the actual VBR bootcode installation helpers into fsutil.c
(they depend on the selected filesystem).

- Introduce InstallBootCodeT

[SETUPLIB] Code re-organization in bootsup.c and fsutil.c.

- 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.

show more ...

[SETUPLIB] Move the filesystem recognition helpers to their own file.

[SETUPLIB][USETUP] Factor out the usage of FS provider structures.

Similarly to FMIFS this structure should be private. Instead file-system
names are passed to the helper functions, allowing to use

[SETUPLIB][USETUP] Factor out the usage of FS provider structures.

Similarly to FMIFS this structure should be private. Instead file-system
names are passed to the helper functions, allowing to use the names
returned by the FS drivers. The names are then internally mapped to the
corresponding FS providers.

In particular this allows to handle the "RAW" file-system and to assign
the 'Unformatted' flag to partitions having this FS.

Finally this helps us refining the checks performed to see whether the
current "active" system partition uses a supported file-system.

show more ...

[USETUP][SETUPLIB] Move the bootsup.c code into the setuplib, and perform the necessary adjustments.

Move the bootsup.c code into the setuplib, as the code is generic
enough to be used by both USETU

[USETUP][SETUPLIB] Move the bootsup.c code into the setuplib, and perform the necessary adjustments.

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

show more ...

[SETUP] Remove myself from the 1st stage setup code

Congratulations Hermès!
You just earned yourself full maintainership of the 1st stage setup. It's yours now. I'm out!

[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib.

- Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem.
- The 'FORMATMACH

[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib.

- Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem.
- The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP.
- Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list.
- Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...).

svn path=/branches/setup_improvements/; revision=74572
svn path=/branches/setup_improvements/; revision=74573

show more ...

[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544

- Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installe

[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544

- 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

show more ...