CORE-16274
SETUPLIB:
=========
- Find the system partition initially when we create the list of
partitions.
- Split the old CheckActiveSystemPartition() helper in two helpers:
FindSupportedSystemPartition() and SetActivePartition(). This allows
simplifying slightly the former one, and allows the user, in an
interactive situation, to decide whether the "supported system
partition" found can actually be used or not.
- Remove the "OriginalSystemPartition" hack in the PARTLIST structure.
- Add a note regarding the SystemPartition member in PARTLIST.
USETUP:
=======
- Use the introduced helpers from above. If the "system" partition we
are going to use, in case we install ReactOS on a fixed disk, is *NOT*
the same as the original one (e.g. because it is detected to be not
supported by ReactOS...), display an informative screen to the user
and let him confirm whether or not he wants to change the partition.
If we install on a fixed disk, try to find a supported system partition
on the system. Otherwise if we install on a removable disk, use the
install partition as the system partition instead.
This allows providing a fix for CORE-16274.
SETUPLIB:
=========
- Remove useless HiddenSectors member in PARTENTRY structure.
- InsertDiskRegion() helper returns a BOOLEAN success.
- CreateInsertBlankRegion() helper sets LogicalPartition.
- Simplify the InitializePartitionEntry() helper so that its PartEntry
parameter is clearly the one that is being initialized (i.e. converted
from a blank region to) an actual partition, and use the helper
CreateInsertBlankRegion(). The calculations for the StartSector and
SectorCount are exactly equivalent with the old version of this
function. Also make it return a BOOLEAN success instead.
+ Add some extra validation checks.
+ Adjust CreatePrimaryPartition(), CreateExtendedPartition() and
CreateLogicalPartition() in this regard.
- Better handling of "RAW"-mounted partitions: treat them as
"Unformatted" only if they are RAW *AND* their PartitionType is one of
those associated with FAT file-system. Otherwise we cannot decide
whether they are indeed unformatted or have an unknown file-system on
them, therefore treat them as the latter.
In this regard, the IsSupportedActivePartition() helper should not
look for FileSystem == RAW but instead only look whether the partition
is Unformatted.
This should help with situations similar to the one described in CORE-16274
where a partition with a genuine file-system but not recognized by
ReactOS (because we currently do not have the EXT2/3/4 filesystem
driver loaded during 1st-stage setup due to commit 5a650f6b) and
therefore mounted as RAW, was thought to be unformatted.
USETUP:
=======
- Use the "global" SystemPartition pointer: this is the "system"
partition we will actually use. It can be different from the actual
one of the computer, for example when we install ReactOS on a
removable disk. This allows also to simplify the code.
- Remove the single-used DestinationDriveLetter variable.
- Remove BuildInstallPaths() helper and use InitDestinationPaths()
directly instead.
- Always mention the disk where the partition being formatted is.
- Cleanup old code comments, add assertions here & there...
- Windows requires 16 bytes of response data.
- Add the PLUGPLAY_CONTROL_USER_RESPONSE_DATA type.
- Usetup and Umpnpmgr must fail if NtPlugPlayControl(PlugPlayControlUserResponse) does not return STATUS_SUCCESS.
Fixes GCC 8 warning:
base/setup/usetup/usetup.c:3407:78: error: '%S' directive writing up to 521 bytes into a region of size 200 [-Werror=format-overflow=]
"Setup is currently unable to check a partition formatted in %S.\n"
^~
base/setup/usetup/usetup.c:3406:9: note: 'sprintf' output between 128 and 649 bytes into a destination of size 260
sprintf(Buffer,
^~~~~~~~~~~~~~~
"Setup is currently unable to check a partition formatted in %S.\n"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"\n"
~~~~
" \x07 Press ENTER to continue Setup.\n"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
" \x07 Press F3 to quit Setup.",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PartEntry->FileSystem);
~~~~~~~~~~~~~~~~~~~~~~
Nowadays more and more people try to install ReactOS from removable
drives (e.g. USB sticks) onto fixed HDDs, or try to install it into
USB sticks too.
Both fixed and removable drives, as well as partitions on these, are
represented in NT using the same device name format:
\Device\HarddiskM\PartitionN ,
with an increasing disk number M. Using this number for building the
corresponding firmware-specific ARC multi(x)disk(y)rdisk(z) path used
by the NT/ROS loader (FreeLdr, ...) is then prone to error since there
may have been removable drives inserted and accounted for in the
calculation of the disk number. These drives must be correctly
subtracted in order to generate the correct ARC path, valid once all
the removable drives have been ejected (which should also be the
situation seen from the BIOS when booting up, except of course if you
boot on a USB stick).
This problem is now solved. Note that it matters only for the disks
that have also been enumerated by the firmware (BIOS; Int 13h). We
don't have to care about the other drives, since the ARC path will be
of a different format and will not use the disk number (instead, the
SCSI coordinates are used).
We also try to enumerate all the disks found in all the possible disk
adapters and controllers enumerated in the Hardware registry tree
(and that are visible by FreeLdr) in order to cover all.
Finally, we detect whether a disk reports as a "super-floppy", i.e.
an unpartitioned disk with a valid VBR. This is indeed how a standard
floppy disk looks like, or how USB sticks are partitioned on Windows.
Such disk is reported has having only one single partition starting at
the beginning of the disk, with partition number == 0, its type being
FAT16 non-bootable.
This allows us to forbid creating any new partitions on such disks.
Note that accessing either \Device\HarddiskN\Partition0 or Partition1
on such a disk returns the same data.
Note also that on the contrary, regular MBR-partitioned disks would
report at least four partitions entries, instead of just one.
The other improvements are:
- Do *NOT* write any MBR on a disk partitioned as "super-floppy".
CORE-13703
- Fix the computed disk identifier, of format: %08x-%08x-%c .
The numbers are respectively the checksum of the first sector, and
the disk signature. The terminating letter is A or X, depending
whether the first sector ends with 0x55AA/0xAA55 or not (see also
commit 5053f1f5).
- Warn if the user attempts to install ReactOS on a disk that is not
visible by the firmware of his computer, because it may not be
bootable.
- 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.
- Find or set the active system partition only once, when we start the
formatting stage. If the system partition is to be created in some
non-partitioned space, we create it.
- A file-system check is always scheduled for both the system and the
installation partitions.
- If the system partition was already formatted (which usually means
that it already existed on the system), don't ask for formatting it.
CORE-13205
- For each partition to be formatted, the file-system menu list is
re-created, in order to display only the FSes that are compatible
with the selected partition, and allow to give the user the choice
to keep the existing file-system only if the selected partition was
already formatted.
- Check whether the user attempts to delete the partition on which
the installation source is present, only if it is not "new" and is
formatted.
- Check first whether the current partition is the system partition,
before displaying the CONFIRM_DELETE_SYSTEM_PARTITION_PAGE.
- Make some partitioning functions not dependent on the selected "CurrentPartition".
- Add some sanity checks.
- Improve some of the "is-partitioned" checks.
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.
- Within the function's body code, check the status values returned by the called functions.
- Change the BuildInstallPaths's function type to NTSTATUS instead of VOID (and check the status of InitDestinationPaths() as well.
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.
- The converter is code7bit I made. code7bit: https://github.com/katahiromz/code7bit
- This converter converts non-clean characters in string literals.
- However I couldn't erase a ton of codepage C4819 warnings.
- CORE-15447
You can edit an European source file as follows:
- Right click the file in the Solution Explorer.
- Select "Open With...".
- Choose "C++ Source Code Editor (with encoding)".
- Choose "Central European (Windows) - Codepage 1260".
- Add checks for GPT disks and either fail or ignore the disk,
depending on the operation being executed.
[USETUP][REACTOS] Display the disk style more accurately.
Always perform the partition validity checks when creating new
primary/extended/logical partitions, and also when a new partition
is automatically created when unpartitioned space is selected for
ReactOS installation.
CORE-12246
Simplified implementation of the proposed solution by George Bișoc
and revised by Victor Perevertkin from PR #952.
NOTE: For whatever reason ERROR_INSTALL_BOOTCODE and ERROR_WRITE_BOOT
seem to be redundant with each other. To be investigated...
Most of Linux filesystems have the MBR ID assigned as 0x83 and when the user chooses BTRFS upon partitions page wizard, we're thinking of the partition as having Ext2 filesystem which is wrong and misleading.
- SETUPLIB and USETUP: Convert PARTENTRY::DriveLetter to WCHAR.
- SETUPLIB: Retrieve volume label.
- SETUPLIB and USETUP: Move the partition types (IDs) table from
USETUP to SETUPLIB so that they can share it with the 1st-stage
GUI installer too. Also take the opportunity to update the table
with information from http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
and cross-checked with the list from Paragon Hard-Disk Manager.
- USETUP: Simplify PrintPartitionData().
- Add some code comments.
- 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).
