[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
2017-05-17 23:37:41 +00:00
|
|
|
/*
|
|
|
|
* PROJECT: ReactOS Setup Library
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
* LICENSE: GPL-2.0-or-later (https://spdx.org/licenses/GPL-2.0-or-later)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
* PURPOSE: Partition list functions
|
2019-02-24 16:52:33 +00:00
|
|
|
* COPYRIGHT: Copyright 2003-2019 Casper S. Hornstrup (chorns@users.sourceforge.net)
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
* Copyright 2018-2024 Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "precomp.h"
|
|
|
|
#include <ntddscsi.h>
|
|
|
|
|
|
|
|
#include "partlist.h"
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
#include "volutil.h"
|
|
|
|
#include "fsrec.h" // For FileSystemToMBRPartitionType()
|
|
|
|
|
2019-12-26 16:16:04 +00:00
|
|
|
#include "registry.h"
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
#define NDEBUG
|
|
|
|
#include <debug.h>
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
// #define DUMP_PARTITION_TABLE
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
#include <pshpack1.h>
|
|
|
|
typedef struct _REG_DISK_MOUNT_INFO
|
|
|
|
{
|
|
|
|
ULONG Signature;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
ULONGLONG StartingOffset;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
} REG_DISK_MOUNT_INFO, *PREG_DISK_MOUNT_INFO;
|
|
|
|
#include <poppack.h>
|
|
|
|
|
|
|
|
|
|
|
|
/* FUNCTIONS ****************************************************************/
|
|
|
|
|
|
|
|
#ifdef DUMP_PARTITION_TABLE
|
|
|
|
static
|
|
|
|
VOID
|
|
|
|
DumpPartitionTable(
|
|
|
|
PDISKENTRY DiskEntry)
|
|
|
|
{
|
|
|
|
PPARTITION_INFORMATION PartitionInfo;
|
|
|
|
ULONG i;
|
|
|
|
|
|
|
|
DbgPrint("\n");
|
|
|
|
DbgPrint("Index Start Length Hidden Nr Type Boot RW\n");
|
|
|
|
DbgPrint("----- ------------ ------------ ---------- -- ---- ---- --\n");
|
|
|
|
|
|
|
|
for (i = 0; i < DiskEntry->LayoutBuffer->PartitionCount; i++)
|
|
|
|
{
|
|
|
|
PartitionInfo = &DiskEntry->LayoutBuffer->PartitionEntry[i];
|
|
|
|
DbgPrint(" %3lu %12I64u %12I64u %10lu %2lu %2x %c %c\n",
|
|
|
|
i,
|
|
|
|
PartitionInfo->StartingOffset.QuadPart / DiskEntry->BytesPerSector,
|
|
|
|
PartitionInfo->PartitionLength.QuadPart / DiskEntry->BytesPerSector,
|
|
|
|
PartitionInfo->HiddenSectors,
|
|
|
|
PartitionInfo->PartitionNumber,
|
|
|
|
PartitionInfo->PartitionType,
|
|
|
|
PartitionInfo->BootIndicator ? '*': ' ',
|
|
|
|
PartitionInfo->RewritePartition ? 'Y': 'N');
|
|
|
|
}
|
|
|
|
|
|
|
|
DbgPrint("\n");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
|
ULONGLONG
|
|
|
|
AlignDown(
|
|
|
|
IN ULONGLONG Value,
|
|
|
|
IN ULONG Alignment)
|
|
|
|
{
|
|
|
|
ULONGLONG Temp;
|
|
|
|
|
|
|
|
Temp = Value / Alignment;
|
|
|
|
|
|
|
|
return Temp * Alignment;
|
|
|
|
}
|
|
|
|
|
|
|
|
ULONGLONG
|
|
|
|
AlignUp(
|
|
|
|
IN ULONGLONG Value,
|
|
|
|
IN ULONG Alignment)
|
|
|
|
{
|
|
|
|
ULONGLONG Temp, Result;
|
|
|
|
|
|
|
|
Temp = Value / Alignment;
|
|
|
|
|
|
|
|
Result = Temp * Alignment;
|
|
|
|
if (Value % Alignment)
|
|
|
|
Result += Alignment;
|
|
|
|
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
ULONGLONG
|
|
|
|
RoundingDivide(
|
|
|
|
IN ULONGLONG Dividend,
|
|
|
|
IN ULONGLONG Divisor)
|
|
|
|
{
|
|
|
|
return (Dividend + Divisor / 2) / Divisor;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static
|
|
|
|
VOID
|
|
|
|
GetDriverName(
|
|
|
|
IN PDISKENTRY DiskEntry)
|
|
|
|
{
|
|
|
|
RTL_QUERY_REGISTRY_TABLE QueryTable[2];
|
|
|
|
WCHAR KeyName[32];
|
|
|
|
NTSTATUS Status;
|
|
|
|
|
2017-05-21 23:34:03 +00:00
|
|
|
RtlInitUnicodeString(&DiskEntry->DriverName, NULL);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2017-05-31 01:43:12 +00:00
|
|
|
RtlStringCchPrintfW(KeyName, ARRAYSIZE(KeyName),
|
|
|
|
L"\\Scsi\\Scsi Port %hu",
|
|
|
|
DiskEntry->Port);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2017-05-21 23:34:03 +00:00
|
|
|
RtlZeroMemory(&QueryTable, sizeof(QueryTable));
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
QueryTable[0].Name = L"Driver";
|
|
|
|
QueryTable[0].Flags = RTL_QUERY_REGISTRY_DIRECT;
|
|
|
|
QueryTable[0].EntryContext = &DiskEntry->DriverName;
|
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
/* This will allocate DiskEntry->DriverName if needed */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = RtlQueryRegistryValues(RTL_REGISTRY_DEVICEMAP,
|
|
|
|
KeyName,
|
|
|
|
QueryTable,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("RtlQueryRegistryValues() failed (Status %lx)\n", Status);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
VOID
|
|
|
|
AssignDriveLetters(
|
|
|
|
IN PPARTLIST List)
|
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
PLIST_ENTRY Entry1;
|
|
|
|
PLIST_ENTRY Entry2;
|
2018-01-28 22:24:06 +00:00
|
|
|
WCHAR Letter;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
Letter = L'C';
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
/* Assign drive letters to primary partitions */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry1 = List->DiskListHead.Flink;
|
|
|
|
Entry1 != &List->DiskListHead;
|
|
|
|
Entry1 = Entry1->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
DiskEntry = CONTAINING_RECORD(Entry1, DISKENTRY, ListEntry);
|
|
|
|
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry2 = DiskEntry->PrimaryPartListHead.Flink;
|
|
|
|
Entry2 != &DiskEntry->PrimaryPartListHead;
|
|
|
|
Entry2 = Entry2->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(Entry2, PARTENTRY, ListEntry);
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!PartEntry->Volume)
|
|
|
|
continue;
|
|
|
|
PartEntry->Volume->Info.DriveLetter = UNICODE_NULL;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
if (PartEntry->IsPartitioned &&
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
!IsContainerPartition(PartEntry->PartitionType) &&
|
|
|
|
(IsRecognizedPartition(PartEntry->PartitionType) ||
|
|
|
|
PartEntry->SectorCount.QuadPart != 0LL))
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (Letter <= L'Z')
|
|
|
|
PartEntry->Volume->Info.DriveLetter = Letter++;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Assign drive letters to logical drives */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry1 = List->DiskListHead.Flink;
|
|
|
|
Entry1 != &List->DiskListHead;
|
|
|
|
Entry1 = Entry1->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
DiskEntry = CONTAINING_RECORD(Entry1, DISKENTRY, ListEntry);
|
|
|
|
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry2 = DiskEntry->LogicalPartListHead.Flink;
|
|
|
|
Entry2 != &DiskEntry->LogicalPartListHead;
|
|
|
|
Entry2 = Entry2->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(Entry2, PARTENTRY, ListEntry);
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!PartEntry->Volume)
|
|
|
|
continue;
|
|
|
|
PartEntry->Volume->Info.DriveLetter = UNICODE_NULL;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (PartEntry->IsPartitioned &&
|
|
|
|
(IsRecognizedPartition(PartEntry->PartitionType) ||
|
|
|
|
PartEntry->SectorCount.QuadPart != 0LL))
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (Letter <= L'Z')
|
|
|
|
PartEntry->Volume->Info.DriveLetter = Letter++;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
DiskIdentifierQueryRoutine(
|
|
|
|
PWSTR ValueName,
|
|
|
|
ULONG ValueType,
|
|
|
|
PVOID ValueData,
|
|
|
|
ULONG ValueLength,
|
|
|
|
PVOID Context,
|
|
|
|
PVOID EntryContext)
|
|
|
|
{
|
|
|
|
PBIOSDISKENTRY BiosDiskEntry = (PBIOSDISKENTRY)Context;
|
|
|
|
UNICODE_STRING NameU;
|
|
|
|
|
|
|
|
if (ValueType == REG_SZ &&
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
ValueLength == 20 * sizeof(WCHAR) &&
|
|
|
|
((PWCHAR)ValueData)[8] == L'-')
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
NameU.Buffer = (PWCHAR)ValueData;
|
|
|
|
NameU.Length = NameU.MaximumLength = 8 * sizeof(WCHAR);
|
|
|
|
RtlUnicodeStringToInteger(&NameU, 16, &BiosDiskEntry->Checksum);
|
|
|
|
|
|
|
|
NameU.Buffer = (PWCHAR)ValueData + 9;
|
|
|
|
RtlUnicodeStringToInteger(&NameU, 16, &BiosDiskEntry->Signature);
|
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
DiskConfigurationDataQueryRoutine(
|
|
|
|
PWSTR ValueName,
|
|
|
|
ULONG ValueType,
|
|
|
|
PVOID ValueData,
|
|
|
|
ULONG ValueLength,
|
|
|
|
PVOID Context,
|
|
|
|
PVOID EntryContext)
|
|
|
|
{
|
|
|
|
PBIOSDISKENTRY BiosDiskEntry = (PBIOSDISKENTRY)Context;
|
|
|
|
PCM_FULL_RESOURCE_DESCRIPTOR FullResourceDescriptor;
|
|
|
|
PCM_DISK_GEOMETRY_DEVICE_DATA DiskGeometry;
|
|
|
|
ULONG i;
|
|
|
|
|
|
|
|
if (ValueType != REG_FULL_RESOURCE_DESCRIPTOR ||
|
|
|
|
ValueLength < sizeof(CM_FULL_RESOURCE_DESCRIPTOR))
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
|
|
|
|
FullResourceDescriptor = (PCM_FULL_RESOURCE_DESCRIPTOR)ValueData;
|
|
|
|
|
|
|
|
/* Hm. Version and Revision are not set on Microsoft Windows XP... */
|
|
|
|
#if 0
|
|
|
|
if (FullResourceDescriptor->PartialResourceList.Version != 1 ||
|
|
|
|
FullResourceDescriptor->PartialResourceList.Revision != 1)
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
for (i = 0; i < FullResourceDescriptor->PartialResourceList.Count; i++)
|
|
|
|
{
|
|
|
|
if (FullResourceDescriptor->PartialResourceList.PartialDescriptors[i].Type != CmResourceTypeDeviceSpecific ||
|
|
|
|
FullResourceDescriptor->PartialResourceList.PartialDescriptors[i].u.DeviceSpecificData.DataSize != sizeof(CM_DISK_GEOMETRY_DEVICE_DATA))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
DiskGeometry = (PCM_DISK_GEOMETRY_DEVICE_DATA)&FullResourceDescriptor->PartialResourceList.PartialDescriptors[i + 1];
|
|
|
|
BiosDiskEntry->DiskGeometry = *DiskGeometry;
|
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
SystemConfigurationDataQueryRoutine(
|
|
|
|
PWSTR ValueName,
|
|
|
|
ULONG ValueType,
|
|
|
|
PVOID ValueData,
|
|
|
|
ULONG ValueLength,
|
|
|
|
PVOID Context,
|
|
|
|
PVOID EntryContext)
|
|
|
|
{
|
|
|
|
PCM_FULL_RESOURCE_DESCRIPTOR FullResourceDescriptor;
|
|
|
|
PCM_INT13_DRIVE_PARAMETER* Int13Drives = (PCM_INT13_DRIVE_PARAMETER*)Context;
|
|
|
|
ULONG i;
|
|
|
|
|
|
|
|
if (ValueType != REG_FULL_RESOURCE_DESCRIPTOR ||
|
|
|
|
ValueLength < sizeof(CM_FULL_RESOURCE_DESCRIPTOR))
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
|
|
|
|
FullResourceDescriptor = (PCM_FULL_RESOURCE_DESCRIPTOR)ValueData;
|
|
|
|
|
|
|
|
/* Hm. Version and Revision are not set on Microsoft Windows XP... */
|
|
|
|
#if 0
|
|
|
|
if (FullResourceDescriptor->PartialResourceList.Version != 1 ||
|
|
|
|
FullResourceDescriptor->PartialResourceList.Revision != 1)
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
for (i = 0; i < FullResourceDescriptor->PartialResourceList.Count; i++)
|
|
|
|
{
|
|
|
|
if (FullResourceDescriptor->PartialResourceList.PartialDescriptors[i].Type != CmResourceTypeDeviceSpecific ||
|
|
|
|
FullResourceDescriptor->PartialResourceList.PartialDescriptors[i].u.DeviceSpecificData.DataSize % sizeof(CM_INT13_DRIVE_PARAMETER) != 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
*Int13Drives = (CM_INT13_DRIVE_PARAMETER*)RtlAllocateHeap(ProcessHeap, 0,
|
|
|
|
FullResourceDescriptor->PartialResourceList.PartialDescriptors[i].u.DeviceSpecificData.DataSize);
|
|
|
|
if (*Int13Drives == NULL)
|
|
|
|
return STATUS_NO_MEMORY;
|
|
|
|
|
|
|
|
memcpy(*Int13Drives,
|
|
|
|
&FullResourceDescriptor->PartialResourceList.PartialDescriptors[i + 1],
|
|
|
|
FullResourceDescriptor->PartialResourceList.PartialDescriptors[i].u.DeviceSpecificData.DataSize);
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static VOID
|
|
|
|
EnumerateBiosDiskEntries(
|
|
|
|
IN PPARTLIST PartList)
|
|
|
|
{
|
|
|
|
RTL_QUERY_REGISTRY_TABLE QueryTable[3];
|
|
|
|
WCHAR Name[120];
|
|
|
|
ULONG AdapterCount;
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
ULONG ControllerCount;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
ULONG DiskCount;
|
|
|
|
NTSTATUS Status;
|
|
|
|
PCM_INT13_DRIVE_PARAMETER Int13Drives;
|
|
|
|
PBIOSDISKENTRY BiosDiskEntry;
|
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
#define ROOT_NAME L"\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System\\MultifunctionAdapter"
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
memset(QueryTable, 0, sizeof(QueryTable));
|
|
|
|
|
|
|
|
QueryTable[1].Name = L"Configuration Data";
|
|
|
|
QueryTable[1].QueryRoutine = SystemConfigurationDataQueryRoutine;
|
|
|
|
Int13Drives = NULL;
|
|
|
|
Status = RtlQueryRegistryValues(RTL_REGISTRY_ABSOLUTE,
|
|
|
|
L"\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System",
|
|
|
|
&QueryTable[1],
|
|
|
|
(PVOID)&Int13Drives,
|
|
|
|
NULL);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("Unable to query the 'Configuration Data' key in '\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System', status=%lx\n", Status);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
for (AdapterCount = 0; ; ++AdapterCount)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2017-05-31 01:43:12 +00:00
|
|
|
RtlStringCchPrintfW(Name, ARRAYSIZE(Name),
|
|
|
|
L"%s\\%lu",
|
|
|
|
ROOT_NAME, AdapterCount);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = RtlQueryRegistryValues(RTL_REGISTRY_ABSOLUTE,
|
|
|
|
Name,
|
|
|
|
&QueryTable[2],
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-05-31 01:43:12 +00:00
|
|
|
RtlStringCchPrintfW(Name, ARRAYSIZE(Name),
|
|
|
|
L"%s\\%lu\\DiskController",
|
|
|
|
ROOT_NAME, AdapterCount);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = RtlQueryRegistryValues(RTL_REGISTRY_ABSOLUTE,
|
|
|
|
Name,
|
|
|
|
&QueryTable[2],
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
for (ControllerCount = 0; ; ++ControllerCount)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2017-05-31 01:43:12 +00:00
|
|
|
RtlStringCchPrintfW(Name, ARRAYSIZE(Name),
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
L"%s\\%lu\\DiskController\\%lu",
|
|
|
|
ROOT_NAME, AdapterCount, ControllerCount);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = RtlQueryRegistryValues(RTL_REGISTRY_ABSOLUTE,
|
|
|
|
Name,
|
|
|
|
&QueryTable[2],
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, Int13Drives);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-05-31 01:43:12 +00:00
|
|
|
RtlStringCchPrintfW(Name, ARRAYSIZE(Name),
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
L"%s\\%lu\\DiskController\\%lu\\DiskPeripheral",
|
|
|
|
ROOT_NAME, AdapterCount, ControllerCount);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = RtlQueryRegistryValues(RTL_REGISTRY_ABSOLUTE,
|
|
|
|
Name,
|
|
|
|
&QueryTable[2],
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
QueryTable[0].Name = L"Identifier";
|
|
|
|
QueryTable[0].QueryRoutine = DiskIdentifierQueryRoutine;
|
|
|
|
QueryTable[1].Name = L"Configuration Data";
|
|
|
|
QueryTable[1].QueryRoutine = DiskConfigurationDataQueryRoutine;
|
|
|
|
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
for (DiskCount = 0; ; ++DiskCount)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
BiosDiskEntry = (BIOSDISKENTRY*)RtlAllocateHeap(ProcessHeap, HEAP_ZERO_MEMORY, sizeof(BIOSDISKENTRY));
|
|
|
|
if (BiosDiskEntry == NULL)
|
|
|
|
{
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
RtlFreeHeap(ProcessHeap, 0, Int13Drives);
|
|
|
|
return;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
2017-05-31 01:43:12 +00:00
|
|
|
RtlStringCchPrintfW(Name, ARRAYSIZE(Name),
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
L"%s\\%lu\\DiskController\\%lu\\DiskPeripheral\\%lu",
|
|
|
|
ROOT_NAME, AdapterCount, ControllerCount, DiskCount);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = RtlQueryRegistryValues(RTL_REGISTRY_ABSOLUTE,
|
|
|
|
Name,
|
|
|
|
QueryTable,
|
|
|
|
(PVOID)BiosDiskEntry,
|
|
|
|
NULL);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, BiosDiskEntry);
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
RtlFreeHeap(ProcessHeap, 0, Int13Drives);
|
|
|
|
return;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
BiosDiskEntry->AdapterNumber = 0; // And NOT "AdapterCount" as it needs to be hardcoded for BIOS!
|
|
|
|
BiosDiskEntry->ControllerNumber = ControllerCount;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
BiosDiskEntry->DiskNumber = DiskCount;
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
BiosDiskEntry->DiskEntry = NULL;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
if (DiskCount < Int13Drives[0].NumberDrives)
|
|
|
|
{
|
|
|
|
BiosDiskEntry->Int13DiskData = Int13Drives[DiskCount];
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
DPRINT1("Didn't find Int13 drive data for disk %u\n", DiskCount);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
InsertTailList(&PartList->BiosDiskListHead, &BiosDiskEntry->ListEntry);
|
|
|
|
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
DPRINT("--->\n");
|
|
|
|
DPRINT("AdapterNumber: %lu\n", BiosDiskEntry->AdapterNumber);
|
|
|
|
DPRINT("ControllerNumber: %lu\n", BiosDiskEntry->ControllerNumber);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
DPRINT("DiskNumber: %lu\n", BiosDiskEntry->DiskNumber);
|
|
|
|
DPRINT("Signature: %08lx\n", BiosDiskEntry->Signature);
|
|
|
|
DPRINT("Checksum: %08lx\n", BiosDiskEntry->Checksum);
|
|
|
|
DPRINT("BytesPerSector: %lu\n", BiosDiskEntry->DiskGeometry.BytesPerSector);
|
|
|
|
DPRINT("NumberOfCylinders: %lu\n", BiosDiskEntry->DiskGeometry.NumberOfCylinders);
|
|
|
|
DPRINT("NumberOfHeads: %lu\n", BiosDiskEntry->DiskGeometry.NumberOfHeads);
|
|
|
|
DPRINT("DriveSelect: %02x\n", BiosDiskEntry->Int13DiskData.DriveSelect);
|
|
|
|
DPRINT("MaxCylinders: %lu\n", BiosDiskEntry->Int13DiskData.MaxCylinders);
|
|
|
|
DPRINT("SectorsPerTrack: %d\n", BiosDiskEntry->Int13DiskData.SectorsPerTrack);
|
|
|
|
DPRINT("MaxHeads: %d\n", BiosDiskEntry->Int13DiskData.MaxHeads);
|
|
|
|
DPRINT("NumberDrives: %d\n", BiosDiskEntry->Int13DiskData.NumberDrives);
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
DPRINT("<---\n");
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, Int13Drives);
|
2018-01-28 22:24:06 +00:00
|
|
|
|
|
|
|
#undef ROOT_NAME
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
/*
|
2024-08-30 21:24:27 +00:00
|
|
|
* Detects whether a disk is a "super-floppy", i.e. an unpartitioned
|
|
|
|
* disk with only a valid VBR, as reported by IoReadPartitionTable()
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
* and IoWritePartitionTable():
|
2024-08-30 21:24:27 +00:00
|
|
|
* only one single partition starting at offset zero and spanning the
|
|
|
|
* whole disk, without hidden sectors, whose type is FAT16 non-bootable.
|
|
|
|
*
|
|
|
|
* Accessing \Device\HarddiskN\Partition0 or Partition1 on such disks
|
|
|
|
* returns the same data.
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
*/
|
|
|
|
BOOLEAN
|
2024-08-30 21:24:27 +00:00
|
|
|
IsDiskSuperFloppy2(
|
|
|
|
_In_ const DISK_PARTITION_INFO* DiskInfo,
|
|
|
|
_In_opt_ const ULONGLONG* DiskSize,
|
|
|
|
_In_ const PARTITION_INFORMATION* PartitionInfo)
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
{
|
2024-08-30 21:24:27 +00:00
|
|
|
/* Structure size must be valid */
|
|
|
|
if (DiskInfo->SizeOfPartitionInfo < RTL_SIZEOF_THROUGH_FIELD(DISK_PARTITION_INFO, Mbr))
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
return FALSE;
|
|
|
|
|
2024-08-30 21:24:27 +00:00
|
|
|
/* The layout must be MBR */
|
|
|
|
if (DiskInfo->PartitionStyle != PARTITION_STYLE_MBR)
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
/* The single partition must start at the beginning of the disk */
|
|
|
|
if (!(PartitionInfo->StartingOffset.QuadPart == 0 &&
|
|
|
|
PartitionInfo->HiddenSectors == 0))
|
|
|
|
{
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2024-08-30 21:24:27 +00:00
|
|
|
/* The disk signature is usually set to 1; warn in case it's not */
|
|
|
|
if (DiskInfo->Mbr.Signature != 1)
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
{
|
2024-08-30 21:24:27 +00:00
|
|
|
DPRINT1("Super-Floppy signature %08x != 1\n", DiskInfo->Mbr.Signature);
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
}
|
|
|
|
|
2024-08-30 21:24:27 +00:00
|
|
|
/* The partition must be recognized and report as FAT16 non-bootable */
|
|
|
|
if ((PartitionInfo->RecognizedPartition != TRUE) ||
|
|
|
|
(PartitionInfo->PartitionType != PARTITION_FAT_16) ||
|
|
|
|
(PartitionInfo->BootIndicator != FALSE))
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
{
|
2024-08-30 21:24:27 +00:00
|
|
|
DPRINT1("Super-Floppy does not return default settings:\n"
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
" RecognizedPartition = %s, expected TRUE\n"
|
|
|
|
" PartitionType = 0x%02x, expected 0x04 (PARTITION_FAT_16)\n"
|
|
|
|
" BootIndicator = %s, expected FALSE\n",
|
|
|
|
PartitionInfo->RecognizedPartition ? "TRUE" : "FALSE",
|
|
|
|
PartitionInfo->PartitionType,
|
|
|
|
PartitionInfo->BootIndicator ? "TRUE" : "FALSE");
|
|
|
|
}
|
|
|
|
|
2024-08-30 21:24:27 +00:00
|
|
|
/* The partition and disk sizes should agree */
|
|
|
|
if (DiskSize && (PartitionInfo->PartitionLength.QuadPart != *DiskSize))
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
{
|
2024-08-30 21:24:27 +00:00
|
|
|
DPRINT1("PartitionLength = %I64u is different from DiskSize = %I64u\n",
|
|
|
|
PartitionInfo->PartitionLength.QuadPart, *DiskSize);
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2024-08-30 21:24:27 +00:00
|
|
|
BOOLEAN
|
|
|
|
IsDiskSuperFloppy(
|
|
|
|
_In_ const DRIVE_LAYOUT_INFORMATION* Layout,
|
|
|
|
_In_opt_ const ULONGLONG* DiskSize)
|
|
|
|
{
|
|
|
|
DISK_PARTITION_INFO DiskInfo;
|
|
|
|
|
|
|
|
/* The layout must contain only one partition */
|
|
|
|
if (Layout->PartitionCount != 1)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
/* Build the disk partition info */
|
|
|
|
DiskInfo.SizeOfPartitionInfo = RTL_SIZEOF_THROUGH_FIELD(DISK_PARTITION_INFO, Mbr);
|
|
|
|
DiskInfo.PartitionStyle = PARTITION_STYLE_MBR;
|
|
|
|
DiskInfo.Mbr.Signature = Layout->Signature;
|
|
|
|
DiskInfo.Mbr.CheckSum = 0; // Dummy value
|
|
|
|
|
|
|
|
/* Call the helper on the single partition entry */
|
|
|
|
return IsDiskSuperFloppy2(&DiskInfo, DiskSize, Layout->PartitionEntry);
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
IsDiskSuperFloppyEx(
|
|
|
|
_In_ const DRIVE_LAYOUT_INFORMATION_EX* LayoutEx,
|
|
|
|
_In_opt_ const ULONGLONG* DiskSize)
|
|
|
|
{
|
|
|
|
DISK_PARTITION_INFO DiskInfo;
|
|
|
|
const PARTITION_INFORMATION_EX* PartitionInfoEx;
|
|
|
|
PARTITION_INFORMATION PartitionInfo;
|
|
|
|
|
|
|
|
/* The layout must be MBR and contain only one partition */
|
|
|
|
if (LayoutEx->PartitionStyle != PARTITION_STYLE_MBR)
|
|
|
|
return FALSE;
|
|
|
|
if (LayoutEx->PartitionCount != 1)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
/* Build the disk partition info */
|
|
|
|
DiskInfo.SizeOfPartitionInfo = RTL_SIZEOF_THROUGH_FIELD(DISK_PARTITION_INFO, Mbr);
|
|
|
|
DiskInfo.PartitionStyle = PARTITION_STYLE_MBR; // LayoutEx->PartitionStyle;
|
|
|
|
DiskInfo.Mbr.Signature = LayoutEx->Mbr.Signature;
|
|
|
|
DiskInfo.Mbr.CheckSum = 0; // Dummy value
|
|
|
|
|
|
|
|
/* Convert the single partition entry */
|
|
|
|
PartitionInfoEx = LayoutEx->PartitionEntry;
|
|
|
|
|
|
|
|
PartitionInfo.StartingOffset = PartitionInfoEx->StartingOffset;
|
|
|
|
PartitionInfo.PartitionLength = PartitionInfoEx->PartitionLength;
|
|
|
|
PartitionInfo.HiddenSectors = PartitionInfoEx->Mbr.HiddenSectors;
|
|
|
|
PartitionInfo.PartitionNumber = PartitionInfoEx->PartitionNumber;
|
|
|
|
PartitionInfo.PartitionType = PartitionInfoEx->Mbr.PartitionType;
|
|
|
|
PartitionInfo.BootIndicator = PartitionInfoEx->Mbr.BootIndicator;
|
|
|
|
PartitionInfo.RecognizedPartition = PartitionInfoEx->Mbr.RecognizedPartition;
|
|
|
|
PartitionInfo.RewritePartition = PartitionInfoEx->RewritePartition;
|
|
|
|
|
|
|
|
/* Call the helper on the single partition entry */
|
|
|
|
return IsDiskSuperFloppy2(&DiskInfo, DiskSize, &PartitionInfo);
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
IsSuperFloppy(
|
|
|
|
_In_ PDISKENTRY DiskEntry)
|
|
|
|
{
|
|
|
|
ULONGLONG DiskSize;
|
|
|
|
|
|
|
|
/* No layout buffer: we cannot say anything yet */
|
|
|
|
if (!DiskEntry->LayoutBuffer)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
/* The disk must be MBR */
|
|
|
|
if (DiskEntry->DiskStyle != PARTITION_STYLE_MBR)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
DiskSize = GetDiskSizeInBytes(DiskEntry);
|
|
|
|
return IsDiskSuperFloppy(DiskEntry->LayoutBuffer, &DiskSize);
|
|
|
|
}
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
|
|
|
|
/*
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
* Inserts the disk region represented by PartEntry into either
|
|
|
|
* the primary or the logical partition list of the given disk.
|
2018-11-22 02:26:47 +00:00
|
|
|
* The lists are kept sorted by increasing order of start sectors.
|
|
|
|
* Of course no disk region should overlap at all with one another.
|
|
|
|
*/
|
|
|
|
static
|
2019-08-24 23:32:46 +00:00
|
|
|
BOOLEAN
|
2018-11-22 02:26:47 +00:00
|
|
|
InsertDiskRegion(
|
|
|
|
IN PDISKENTRY DiskEntry,
|
|
|
|
IN PPARTENTRY PartEntry,
|
|
|
|
IN BOOLEAN LogicalPartition)
|
|
|
|
{
|
|
|
|
PLIST_ENTRY List;
|
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
PPARTENTRY PartEntry2;
|
|
|
|
|
|
|
|
/* Use the correct partition list */
|
|
|
|
if (LogicalPartition)
|
|
|
|
List = &DiskEntry->LogicalPartListHead;
|
|
|
|
else
|
|
|
|
List = &DiskEntry->PrimaryPartListHead;
|
|
|
|
|
|
|
|
/* Find the first disk region before which we need to insert the new one */
|
|
|
|
for (Entry = List->Flink; Entry != List; Entry = Entry->Flink)
|
|
|
|
{
|
|
|
|
PartEntry2 = CONTAINING_RECORD(Entry, PARTENTRY, ListEntry);
|
|
|
|
|
|
|
|
/* Ignore any unused empty region */
|
|
|
|
if ((PartEntry2->PartitionType == PARTITION_ENTRY_UNUSED &&
|
|
|
|
PartEntry2->StartSector.QuadPart == 0) || PartEntry2->SectorCount.QuadPart == 0)
|
|
|
|
{
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If the current region ends before the one to be inserted, try again */
|
|
|
|
if (PartEntry2->StartSector.QuadPart + PartEntry2->SectorCount.QuadPart - 1 < PartEntry->StartSector.QuadPart)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* One of the disk region boundaries crosses the desired region
|
|
|
|
* (it starts after the desired region, or ends before the end
|
|
|
|
* of the desired region): this is an impossible situation because
|
|
|
|
* disk regions (partitions) cannot overlap!
|
|
|
|
* Throw an error and bail out.
|
|
|
|
*/
|
|
|
|
if (max(PartEntry->StartSector.QuadPart, PartEntry2->StartSector.QuadPart)
|
|
|
|
<=
|
|
|
|
min( PartEntry->StartSector.QuadPart + PartEntry->SectorCount.QuadPart - 1,
|
|
|
|
PartEntry2->StartSector.QuadPart + PartEntry2->SectorCount.QuadPart - 1))
|
|
|
|
{
|
|
|
|
DPRINT1("Disk region overlap problem, stopping there!\n"
|
|
|
|
"Partition to be inserted:\n"
|
|
|
|
" StartSector = %I64u ; EndSector = %I64u\n"
|
|
|
|
"Existing disk region:\n"
|
|
|
|
" StartSector = %I64u ; EndSector = %I64u\n",
|
|
|
|
PartEntry->StartSector.QuadPart,
|
|
|
|
PartEntry->StartSector.QuadPart + PartEntry->SectorCount.QuadPart - 1,
|
|
|
|
PartEntry2->StartSector.QuadPart,
|
|
|
|
PartEntry2->StartSector.QuadPart + PartEntry2->SectorCount.QuadPart - 1);
|
2019-08-24 23:32:46 +00:00
|
|
|
return FALSE;
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* We have found the first region before which the new one has to be inserted */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Insert the disk region */
|
|
|
|
InsertTailList(Entry, &PartEntry->ListEntry);
|
2019-08-24 23:32:46 +00:00
|
|
|
return TRUE;
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
PPARTENTRY
|
|
|
|
CreateInsertBlankRegion(
|
|
|
|
IN PDISKENTRY DiskEntry,
|
|
|
|
IN OUT PLIST_ENTRY ListHead,
|
|
|
|
IN ULONGLONG StartSector,
|
|
|
|
IN ULONGLONG SectorCount,
|
|
|
|
IN BOOLEAN LogicalSpace)
|
|
|
|
{
|
|
|
|
PPARTENTRY NewPartEntry;
|
|
|
|
|
|
|
|
NewPartEntry = RtlAllocateHeap(ProcessHeap,
|
|
|
|
HEAP_ZERO_MEMORY,
|
|
|
|
sizeof(PARTENTRY));
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!NewPartEntry)
|
2018-11-22 02:26:47 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
NewPartEntry->DiskEntry = DiskEntry;
|
|
|
|
|
|
|
|
NewPartEntry->StartSector.QuadPart = StartSector;
|
|
|
|
NewPartEntry->SectorCount.QuadPart = SectorCount;
|
|
|
|
|
2019-08-24 23:32:46 +00:00
|
|
|
NewPartEntry->LogicalPartition = LogicalSpace;
|
2019-02-24 16:52:33 +00:00
|
|
|
NewPartEntry->IsPartitioned = FALSE;
|
|
|
|
NewPartEntry->PartitionType = PARTITION_ENTRY_UNUSED;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
NewPartEntry->Volume = NULL;
|
2019-02-24 16:52:33 +00:00
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
DPRINT1("First Sector : %I64u\n", NewPartEntry->StartSector.QuadPart);
|
|
|
|
DPRINT1("Last Sector : %I64u\n", NewPartEntry->StartSector.QuadPart + NewPartEntry->SectorCount.QuadPart - 1);
|
|
|
|
DPRINT1("Total Sectors: %I64u\n", NewPartEntry->SectorCount.QuadPart);
|
|
|
|
|
2019-02-24 16:52:33 +00:00
|
|
|
/* Insert the new entry into the list */
|
2018-11-22 02:26:47 +00:00
|
|
|
InsertTailList(ListHead, &NewPartEntry->ListEntry);
|
|
|
|
|
|
|
|
return NewPartEntry;
|
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
static
|
|
|
|
VOID
|
|
|
|
DestroyRegion(
|
|
|
|
_Inout_ PPARTENTRY PartEntry)
|
|
|
|
{
|
|
|
|
// RemoveEntryList(&PartEntry->Volume->ListEntry);
|
|
|
|
if (PartEntry->Volume)
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, PartEntry->Volume);
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, PartEntry);
|
|
|
|
}
|
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
static
|
|
|
|
VOID
|
|
|
|
AddLogicalDiskSpace(
|
|
|
|
_In_ PDISKENTRY DiskEntry)
|
|
|
|
{
|
|
|
|
ULONGLONG StartSector;
|
|
|
|
ULONGLONG SectorCount;
|
|
|
|
PPARTENTRY NewPartEntry;
|
|
|
|
|
|
|
|
DPRINT("AddLogicalDiskSpace()\n");
|
|
|
|
|
|
|
|
/* Create a partition entry that represents the empty space in the container partition */
|
|
|
|
|
|
|
|
StartSector = DiskEntry->ExtendedPartition->StartSector.QuadPart + (ULONGLONG)DiskEntry->SectorAlignment;
|
|
|
|
SectorCount = DiskEntry->ExtendedPartition->SectorCount.QuadPart - (ULONGLONG)DiskEntry->SectorAlignment;
|
|
|
|
|
|
|
|
NewPartEntry = CreateInsertBlankRegion(DiskEntry,
|
|
|
|
&DiskEntry->LogicalPartListHead,
|
|
|
|
StartSector,
|
|
|
|
SectorCount,
|
|
|
|
TRUE);
|
|
|
|
if (!NewPartEntry)
|
|
|
|
DPRINT1("Failed to create a new empty region for full extended partition space!\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO: Improve upon the PartitionInfo parameter later
|
|
|
|
// (see VDS::CREATE_PARTITION_PARAMETERS and PPARTITION_INFORMATION_MBR/GPT for example)
|
|
|
|
// So far we only use it as the optional type of the partition to create.
|
|
|
|
//
|
|
|
|
// See also CreatePartition().
|
2018-11-22 02:26:47 +00:00
|
|
|
static
|
2019-08-24 23:32:46 +00:00
|
|
|
BOOLEAN
|
2018-11-22 02:26:47 +00:00
|
|
|
InitializePartitionEntry(
|
2023-12-07 22:29:28 +00:00
|
|
|
_Inout_ PPARTENTRY PartEntry,
|
2024-06-06 20:19:04 +00:00
|
|
|
_In_opt_ ULONGLONG SizeBytes,
|
|
|
|
_In_opt_ ULONG_PTR PartitionInfo)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
2019-08-24 23:32:46 +00:00
|
|
|
PDISKENTRY DiskEntry = PartEntry->DiskEntry;
|
2023-12-07 22:29:28 +00:00
|
|
|
ULONGLONG SectorCount;
|
2024-06-06 20:19:04 +00:00
|
|
|
BOOLEAN isContainer = IsContainerPartition((UCHAR)PartitionInfo);
|
2023-12-07 22:29:28 +00:00
|
|
|
|
|
|
|
DPRINT1("Current entry sector count: %I64u\n", PartEntry->SectorCount.QuadPart);
|
2018-11-22 02:26:47 +00:00
|
|
|
|
2023-12-07 22:29:28 +00:00
|
|
|
/* The entry must not be already partitioned and not be void */
|
|
|
|
ASSERT(!PartEntry->IsPartitioned);
|
|
|
|
ASSERT(PartEntry->SectorCount.QuadPart);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
ASSERT(!PartEntry->Volume);
|
2023-12-07 22:29:28 +00:00
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
/* Either we create a primary/logical partition, or we create an
|
|
|
|
* extended partition but the entry must not be logical space */
|
|
|
|
ASSERT(!isContainer || !PartEntry->LogicalPartition);
|
|
|
|
|
2023-12-07 22:29:28 +00:00
|
|
|
/* Convert the size in bytes to sector count. SizeBytes being
|
|
|
|
* zero means the caller wants to use all the empty space. */
|
|
|
|
if ((SizeBytes == 0) || (SizeBytes == GetPartEntrySizeInBytes(PartEntry)))
|
|
|
|
{
|
|
|
|
/* Use all of the unpartitioned disk space */
|
|
|
|
SectorCount = PartEntry->SectorCount.QuadPart;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
SectorCount = SizeBytes / DiskEntry->BytesPerSector;
|
|
|
|
if (SectorCount == 0)
|
|
|
|
{
|
|
|
|
/* SizeBytes was certainly less than the minimal size, so fail */
|
|
|
|
DPRINT1("Partition size %I64u too small\n", SizeBytes);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
DPRINT1(" New sector count: %I64u\n", SectorCount);
|
2018-11-22 02:26:47 +00:00
|
|
|
|
2023-12-07 22:29:28 +00:00
|
|
|
/* Fail if we request more sectors than what the entry actually contains */
|
2019-08-24 23:32:46 +00:00
|
|
|
if (SectorCount > PartEntry->SectorCount.QuadPart)
|
|
|
|
return FALSE;
|
|
|
|
|
2023-12-07 22:29:28 +00:00
|
|
|
if ((SectorCount == 0) ||
|
2018-11-22 02:26:47 +00:00
|
|
|
(AlignDown(PartEntry->StartSector.QuadPart + SectorCount, DiskEntry->SectorAlignment) -
|
|
|
|
PartEntry->StartSector.QuadPart == PartEntry->SectorCount.QuadPart))
|
|
|
|
{
|
2023-12-07 22:29:28 +00:00
|
|
|
/* Reuse the whole current entry */
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2019-08-24 23:32:46 +00:00
|
|
|
ULONGLONG StartSector;
|
|
|
|
ULONGLONG SectorCount2;
|
|
|
|
PPARTENTRY NewPartEntry;
|
2018-11-22 02:26:47 +00:00
|
|
|
|
2023-12-07 22:29:28 +00:00
|
|
|
/* Create a partition entry that represents the remaining space
|
|
|
|
* after the partition to be initialized */
|
2018-11-22 02:26:47 +00:00
|
|
|
|
2019-08-24 23:32:46 +00:00
|
|
|
StartSector = AlignDown(PartEntry->StartSector.QuadPart + SectorCount, DiskEntry->SectorAlignment);
|
|
|
|
SectorCount2 = PartEntry->StartSector.QuadPart + PartEntry->SectorCount.QuadPart - StartSector;
|
2018-11-22 02:26:47 +00:00
|
|
|
|
2019-08-24 23:32:46 +00:00
|
|
|
NewPartEntry = CreateInsertBlankRegion(DiskEntry,
|
|
|
|
PartEntry->ListEntry.Flink,
|
|
|
|
StartSector,
|
|
|
|
SectorCount2,
|
|
|
|
PartEntry->LogicalPartition);
|
2024-06-06 20:19:04 +00:00
|
|
|
if (!NewPartEntry)
|
2019-08-24 23:32:46 +00:00
|
|
|
{
|
|
|
|
DPRINT1("Failed to create a new empty region for disk space!\n");
|
|
|
|
return FALSE;
|
|
|
|
}
|
2019-02-24 16:52:33 +00:00
|
|
|
|
2019-08-24 23:32:46 +00:00
|
|
|
/* Resize down the partition entry; its StartSector remains the same */
|
|
|
|
PartEntry->SectorCount.QuadPart = StartSector - PartEntry->StartSector.QuadPart;
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Convert to a new partition entry */
|
2019-08-24 23:32:46 +00:00
|
|
|
PartEntry->New = TRUE;
|
|
|
|
PartEntry->IsPartitioned = TRUE;
|
2019-02-24 16:52:33 +00:00
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
PartEntry->BootIndicator = FALSE;
|
|
|
|
if (PartitionInfo)
|
|
|
|
{
|
|
|
|
if (!isContainer)
|
|
|
|
{
|
|
|
|
PartEntry->PartitionType = (UCHAR)PartitionInfo;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Set the correct extended container partition type,
|
|
|
|
* depending on whether it is contained below or above
|
|
|
|
* the 1024-cylinder (usually 8.4GB/7.8GiB) boundary:
|
|
|
|
* - below: INT13h CHS partition;
|
|
|
|
* - above: Extended INT13h LBA partition. */
|
|
|
|
if ((PartEntry->StartSector.QuadPart + PartEntry->SectorCount.QuadPart - 1)
|
|
|
|
/ (DiskEntry->TracksPerCylinder * DiskEntry->SectorsPerTrack) < 1024)
|
|
|
|
{
|
|
|
|
PartEntry->PartitionType = PARTITION_EXTENDED;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
PartEntry->PartitionType = PARTITION_XINT13_EXTENDED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2020-11-24 00:49:41 +00:00
|
|
|
// FIXME: Use FileSystemToMBRPartitionType() only for MBR, otherwise use PARTITION_BASIC_DATA_GUID.
|
2024-06-06 20:19:04 +00:00
|
|
|
ASSERT(!isContainer);
|
|
|
|
PartEntry->PartitionType = FileSystemToMBRPartitionType(L"RAW",
|
|
|
|
PartEntry->StartSector.QuadPart,
|
|
|
|
PartEntry->SectorCount.QuadPart);
|
|
|
|
}
|
2019-08-24 23:32:46 +00:00
|
|
|
ASSERT(PartEntry->PartitionType != PARTITION_ENTRY_UNUSED);
|
2019-02-24 16:52:33 +00:00
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
if (isContainer)
|
|
|
|
{
|
|
|
|
DiskEntry->ExtendedPartition = PartEntry;
|
|
|
|
AddLogicalDiskSpace(DiskEntry);
|
|
|
|
}
|
2019-02-24 16:52:33 +00:00
|
|
|
|
2019-08-24 23:32:46 +00:00
|
|
|
DPRINT1("First Sector : %I64u\n", PartEntry->StartSector.QuadPart);
|
|
|
|
DPRINT1("Last Sector : %I64u\n", PartEntry->StartSector.QuadPart + PartEntry->SectorCount.QuadPart - 1);
|
|
|
|
DPRINT1("Total Sectors: %I64u\n", PartEntry->SectorCount.QuadPart);
|
2018-11-22 02:26:47 +00:00
|
|
|
|
2019-08-24 23:32:46 +00:00
|
|
|
return TRUE;
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
static
|
|
|
|
VOID
|
|
|
|
InitPartitionDeviceName(
|
|
|
|
_Inout_ PPARTENTRY PartEntry)
|
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
|
|
|
|
|
|
|
/* Ignore if this is a container partition */
|
|
|
|
if (IsContainerPartition(PartEntry->PartitionType))
|
|
|
|
return;
|
|
|
|
ASSERT(PartEntry->IsPartitioned && PartEntry->PartitionNumber != 0);
|
|
|
|
|
|
|
|
/* Make a device name for the partition */
|
|
|
|
Status = RtlStringCchPrintfW(PartEntry->DeviceName,
|
|
|
|
_countof(PartEntry->DeviceName),
|
|
|
|
L"\\Device\\Harddisk%lu\\Partition%lu",
|
|
|
|
PartEntry->DiskEntry->DiskNumber,
|
|
|
|
PartEntry->PartitionNumber);
|
|
|
|
ASSERT(NT_SUCCESS(Status));
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
VOID
|
|
|
|
InitVolumeDeviceName(
|
|
|
|
_Inout_ PVOLENTRY Volume)
|
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
|
|
|
|
/* If we already have a volume device name, do nothing more */
|
|
|
|
if (*Volume->Info.DeviceName)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Use the partition device name as a temporary volume device name */
|
|
|
|
// TODO: Ask instead the MOUNTMGR for the name.
|
|
|
|
PartEntry = Volume->PartEntry;
|
|
|
|
ASSERT(PartEntry);
|
|
|
|
ASSERT(PartEntry->IsPartitioned && PartEntry->PartitionNumber != 0);
|
|
|
|
|
|
|
|
/* Copy the volume device name */
|
|
|
|
Status = RtlStringCchCopyW(Volume->Info.DeviceName,
|
|
|
|
_countof(Volume->Info.DeviceName),
|
|
|
|
PartEntry->DeviceName);
|
|
|
|
ASSERT(NT_SUCCESS(Status));
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
PVOLENTRY
|
|
|
|
InitVolume(
|
|
|
|
_In_ PPARTLIST List,
|
|
|
|
_In_opt_ PPARTENTRY PartEntry)
|
|
|
|
{
|
|
|
|
PVOLENTRY Volume;
|
|
|
|
|
|
|
|
Volume = RtlAllocateHeap(ProcessHeap,
|
|
|
|
HEAP_ZERO_MEMORY,
|
|
|
|
sizeof(VOLENTRY));
|
|
|
|
if (!Volume)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* Reset some volume information */
|
|
|
|
|
|
|
|
/* No device name for now */
|
|
|
|
Volume->Info.DeviceName[0] = UNICODE_NULL;
|
|
|
|
// Volume->Info.VolumeName[0] = UNICODE_NULL;
|
|
|
|
|
|
|
|
/* Initialize the volume letter and label */
|
|
|
|
Volume->Info.DriveLetter = UNICODE_NULL;
|
|
|
|
Volume->Info.VolumeLabel[0] = UNICODE_NULL;
|
|
|
|
|
|
|
|
/* Specify the volume as initially unformatted */
|
|
|
|
Volume->Info.FileSystem[0] = UNICODE_NULL;
|
|
|
|
Volume->FormatState = Unformatted;
|
|
|
|
Volume->NeedsCheck = FALSE;
|
|
|
|
Volume->New = TRUE;
|
|
|
|
|
|
|
|
if (PartEntry)
|
|
|
|
{
|
|
|
|
ASSERT(PartEntry->DiskEntry->PartList == List);
|
|
|
|
Volume->PartEntry = PartEntry;
|
|
|
|
}
|
|
|
|
InsertTailList(&List->VolumesList, &Volume->ListEntry);
|
|
|
|
return Volume;
|
|
|
|
}
|
2018-11-22 02:26:47 +00:00
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
static
|
|
|
|
VOID
|
|
|
|
AddPartitionToDisk(
|
|
|
|
IN ULONG DiskNumber,
|
|
|
|
IN PDISKENTRY DiskEntry,
|
|
|
|
IN ULONG PartitionIndex,
|
|
|
|
IN BOOLEAN LogicalPartition)
|
|
|
|
{
|
|
|
|
PPARTITION_INFORMATION PartitionInfo;
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
|
|
|
|
PartitionInfo = &DiskEntry->LayoutBuffer->PartitionEntry[PartitionIndex];
|
2017-05-17 23:31:52 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Ignore empty partitions */
|
|
|
|
if (PartitionInfo->PartitionType == PARTITION_ENTRY_UNUSED)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Request must be consistent, though! */
|
|
|
|
ASSERT(!(LogicalPartition && IsContainerPartition(PartitionInfo->PartitionType)));
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
PartEntry = RtlAllocateHeap(ProcessHeap,
|
|
|
|
HEAP_ZERO_MEMORY,
|
|
|
|
sizeof(PARTENTRY));
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!PartEntry)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
PartEntry->DiskEntry = DiskEntry;
|
|
|
|
|
|
|
|
PartEntry->StartSector.QuadPart = (ULONGLONG)PartitionInfo->StartingOffset.QuadPart / DiskEntry->BytesPerSector;
|
|
|
|
PartEntry->SectorCount.QuadPart = (ULONGLONG)PartitionInfo->PartitionLength.QuadPart / DiskEntry->BytesPerSector;
|
|
|
|
|
|
|
|
PartEntry->BootIndicator = PartitionInfo->BootIndicator;
|
|
|
|
PartEntry->PartitionType = PartitionInfo->PartitionType;
|
|
|
|
|
|
|
|
PartEntry->LogicalPartition = LogicalPartition;
|
|
|
|
PartEntry->IsPartitioned = TRUE;
|
2018-11-22 02:26:47 +00:00
|
|
|
PartEntry->OnDiskPartitionNumber = PartitionInfo->PartitionNumber;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartEntry->PartitionNumber = PartitionInfo->PartitionNumber;
|
|
|
|
PartEntry->PartitionIndex = PartitionIndex;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
InitPartitionDeviceName(PartEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* No volume initially */
|
|
|
|
PartEntry->Volume = NULL;
|
2019-02-24 16:52:33 +00:00
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
if (IsContainerPartition(PartEntry->PartitionType))
|
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!LogicalPartition && DiskEntry->ExtendedPartition == NULL)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
DiskEntry->ExtendedPartition = PartEntry;
|
|
|
|
}
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
else if (IsRecognizedPartition(PartEntry->PartitionType) || // PartitionInfo->RecognizedPartition
|
|
|
|
IsOEMPartition(PartEntry->PartitionType))
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PVOLENTRY Volume;
|
|
|
|
NTSTATUS Status;
|
2018-01-28 22:24:06 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
ASSERT(PartEntry->PartitionNumber != 0);
|
2019-08-24 23:32:46 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* The PARTMGR should have notified the MOUNTMGR that a volume
|
|
|
|
* associated with this partition had to be created */
|
|
|
|
Volume = InitVolume(DiskEntry->PartList, PartEntry);
|
|
|
|
if (!Volume)
|
2018-01-28 22:24:06 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
DPRINT1("Couldn't allocate a volume for device '%S'\n",
|
|
|
|
PartEntry->DeviceName);
|
|
|
|
goto SkipVolume;
|
2018-01-28 22:24:06 +00:00
|
|
|
}
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PartEntry->Volume = Volume;
|
|
|
|
InitVolumeDeviceName(Volume);
|
|
|
|
Volume->New = FALSE;
|
2019-02-24 16:52:33 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Attach and mount the volume */
|
|
|
|
Status = MountVolume(&Volume->Info, PartEntry->PartitionType);
|
|
|
|
if (!NT_SUCCESS(Status))
|
2019-02-24 16:52:33 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
DPRINT1("Failed to mount volume '%S', Status 0x%08lx\n",
|
|
|
|
Volume->Info.DeviceName, Status);
|
2019-02-24 16:52:33 +00:00
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
//
|
|
|
|
// FIXME: TEMP Backward-compatibility: Set the FormatState
|
|
|
|
// flag in accordance with the FileSystem volume value.
|
|
|
|
//
|
|
|
|
/*
|
|
|
|
* MountVolume() determines whether the given volume is actually
|
|
|
|
* unformatted, if it was mounted with RawFS and the partition
|
|
|
|
* type has specific values for FAT volumes. If so, the volume
|
|
|
|
* stays mounted with RawFS (the FileSystem is "RAW"). However,
|
|
|
|
* if the partition type has different values, the volume is
|
|
|
|
* considered as having an unknown format (it may or may not be
|
|
|
|
* formatted) and the FileSystem value has been emptied.
|
|
|
|
*/
|
|
|
|
if (IsUnknown(&Volume->Info))
|
|
|
|
Volume->FormatState = UnknownFormat;
|
|
|
|
else if (IsUnformatted(&Volume->Info)) // FileSystem is "RAW"
|
|
|
|
Volume->FormatState = Unformatted;
|
|
|
|
else // !IsUnknown && !IsUnformatted == IsFormatted
|
|
|
|
Volume->FormatState = Formatted;
|
|
|
|
SkipVolume:;
|
2018-01-28 22:24:06 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Unknown partition (may or may not be actually formatted):
|
|
|
|
* the partition is hidden, hence no volume */
|
|
|
|
DPRINT1("Disk %lu Partition %lu is not recognized (Type 0x%02x)\n",
|
|
|
|
DiskEntry->DiskNumber, PartEntry->PartitionNumber,
|
|
|
|
PartEntry->PartitionType);
|
2018-01-28 22:24:06 +00:00
|
|
|
}
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
InsertDiskRegion(DiskEntry, PartEntry, LogicalPartition);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
VOID
|
|
|
|
ScanForUnpartitionedDiskSpace(
|
|
|
|
IN PDISKENTRY DiskEntry)
|
|
|
|
{
|
2018-11-22 02:26:47 +00:00
|
|
|
ULONGLONG StartSector;
|
|
|
|
ULONGLONG SectorCount;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
ULONGLONG LastStartSector;
|
|
|
|
ULONGLONG LastSectorCount;
|
|
|
|
ULONGLONG LastUnusedSectorCount;
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
PPARTENTRY NewPartEntry;
|
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
|
|
|
|
DPRINT("ScanForUnpartitionedDiskSpace()\n");
|
|
|
|
|
|
|
|
if (IsListEmpty(&DiskEntry->PrimaryPartListHead))
|
|
|
|
{
|
|
|
|
DPRINT1("No primary partition!\n");
|
|
|
|
|
|
|
|
/* Create a partition entry that represents the empty disk */
|
|
|
|
|
2018-11-11 16:34:35 +00:00
|
|
|
if (DiskEntry->SectorAlignment < 2048)
|
2018-11-22 02:26:47 +00:00
|
|
|
StartSector = 2048ULL;
|
2018-11-11 16:34:35 +00:00
|
|
|
else
|
2018-11-22 02:26:47 +00:00
|
|
|
StartSector = (ULONGLONG)DiskEntry->SectorAlignment;
|
|
|
|
SectorCount = AlignDown(DiskEntry->SectorCount.QuadPart, DiskEntry->SectorAlignment) - StartSector;
|
|
|
|
|
|
|
|
NewPartEntry = CreateInsertBlankRegion(DiskEntry,
|
|
|
|
&DiskEntry->PrimaryPartListHead,
|
|
|
|
StartSector,
|
|
|
|
SectorCount,
|
|
|
|
FALSE);
|
2024-06-06 20:19:04 +00:00
|
|
|
if (!NewPartEntry)
|
2018-11-22 02:26:47 +00:00
|
|
|
DPRINT1("Failed to create a new empty region for full disk space!\n");
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Start partition at head 1, cylinder 0 */
|
2018-11-11 16:34:35 +00:00
|
|
|
if (DiskEntry->SectorAlignment < 2048)
|
|
|
|
LastStartSector = 2048ULL;
|
|
|
|
else
|
2018-11-22 02:26:47 +00:00
|
|
|
LastStartSector = (ULONGLONG)DiskEntry->SectorAlignment;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
LastSectorCount = 0ULL;
|
|
|
|
LastUnusedSectorCount = 0ULL;
|
|
|
|
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry = DiskEntry->PrimaryPartListHead.Flink;
|
|
|
|
Entry != &DiskEntry->PrimaryPartListHead;
|
|
|
|
Entry = Entry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(Entry, PARTENTRY, ListEntry);
|
|
|
|
|
|
|
|
if (PartEntry->PartitionType != PARTITION_ENTRY_UNUSED ||
|
|
|
|
PartEntry->SectorCount.QuadPart != 0ULL)
|
|
|
|
{
|
|
|
|
LastUnusedSectorCount =
|
|
|
|
PartEntry->StartSector.QuadPart - (LastStartSector + LastSectorCount);
|
|
|
|
|
|
|
|
if (PartEntry->StartSector.QuadPart > (LastStartSector + LastSectorCount) &&
|
|
|
|
LastUnusedSectorCount >= (ULONGLONG)DiskEntry->SectorAlignment)
|
|
|
|
{
|
|
|
|
DPRINT("Unpartitioned disk space %I64u sectors\n", LastUnusedSectorCount);
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
StartSector = LastStartSector + LastSectorCount;
|
|
|
|
SectorCount = AlignDown(StartSector + LastUnusedSectorCount, DiskEntry->SectorAlignment) - StartSector;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
/* Insert the table into the list */
|
2018-11-22 02:26:47 +00:00
|
|
|
NewPartEntry = CreateInsertBlankRegion(DiskEntry,
|
|
|
|
&PartEntry->ListEntry,
|
|
|
|
StartSector,
|
|
|
|
SectorCount,
|
|
|
|
FALSE);
|
2024-06-06 20:19:04 +00:00
|
|
|
if (!NewPartEntry)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
|
|
|
DPRINT1("Failed to create a new empty region for disk space!\n");
|
|
|
|
return;
|
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
LastStartSector = PartEntry->StartSector.QuadPart;
|
|
|
|
LastSectorCount = PartEntry->SectorCount.QuadPart;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for trailing unpartitioned disk space */
|
|
|
|
if ((LastStartSector + LastSectorCount) < DiskEntry->SectorCount.QuadPart)
|
|
|
|
{
|
|
|
|
LastUnusedSectorCount = AlignDown(DiskEntry->SectorCount.QuadPart - (LastStartSector + LastSectorCount), DiskEntry->SectorAlignment);
|
|
|
|
|
|
|
|
if (LastUnusedSectorCount >= (ULONGLONG)DiskEntry->SectorAlignment)
|
|
|
|
{
|
|
|
|
DPRINT("Unpartitioned disk space: %I64u sectors\n", LastUnusedSectorCount);
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
StartSector = LastStartSector + LastSectorCount;
|
|
|
|
SectorCount = AlignDown(StartSector + LastUnusedSectorCount, DiskEntry->SectorAlignment) - StartSector;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
/* Append the table to the list */
|
2018-11-22 02:26:47 +00:00
|
|
|
NewPartEntry = CreateInsertBlankRegion(DiskEntry,
|
|
|
|
&DiskEntry->PrimaryPartListHead,
|
|
|
|
StartSector,
|
|
|
|
SectorCount,
|
|
|
|
FALSE);
|
2024-06-06 20:19:04 +00:00
|
|
|
if (!NewPartEntry)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
|
|
|
DPRINT1("Failed to create a new empty region for trailing disk space!\n");
|
|
|
|
return;
|
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (DiskEntry->ExtendedPartition != NULL)
|
|
|
|
{
|
|
|
|
if (IsListEmpty(&DiskEntry->LogicalPartListHead))
|
|
|
|
{
|
|
|
|
DPRINT1("No logical partition!\n");
|
|
|
|
|
|
|
|
/* Create a partition entry that represents the empty extended partition */
|
2024-06-06 20:19:04 +00:00
|
|
|
AddLogicalDiskSpace(DiskEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Start partition at head 1, cylinder 0 */
|
|
|
|
LastStartSector = DiskEntry->ExtendedPartition->StartSector.QuadPart + (ULONGLONG)DiskEntry->SectorAlignment;
|
|
|
|
LastSectorCount = 0ULL;
|
|
|
|
LastUnusedSectorCount = 0ULL;
|
|
|
|
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry = DiskEntry->LogicalPartListHead.Flink;
|
|
|
|
Entry != &DiskEntry->LogicalPartListHead;
|
|
|
|
Entry = Entry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(Entry, PARTENTRY, ListEntry);
|
|
|
|
|
|
|
|
if (PartEntry->PartitionType != PARTITION_ENTRY_UNUSED ||
|
|
|
|
PartEntry->SectorCount.QuadPart != 0ULL)
|
|
|
|
{
|
|
|
|
LastUnusedSectorCount =
|
|
|
|
PartEntry->StartSector.QuadPart - (ULONGLONG)DiskEntry->SectorAlignment - (LastStartSector + LastSectorCount);
|
|
|
|
|
|
|
|
if ((PartEntry->StartSector.QuadPart - (ULONGLONG)DiskEntry->SectorAlignment) > (LastStartSector + LastSectorCount) &&
|
|
|
|
LastUnusedSectorCount >= (ULONGLONG)DiskEntry->SectorAlignment)
|
|
|
|
{
|
|
|
|
DPRINT("Unpartitioned disk space %I64u sectors\n", LastUnusedSectorCount);
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
StartSector = LastStartSector + LastSectorCount;
|
|
|
|
SectorCount = AlignDown(StartSector + LastUnusedSectorCount, DiskEntry->SectorAlignment) - StartSector;
|
|
|
|
|
|
|
|
/* Insert the table into the list */
|
|
|
|
NewPartEntry = CreateInsertBlankRegion(DiskEntry,
|
|
|
|
&PartEntry->ListEntry,
|
|
|
|
StartSector,
|
|
|
|
SectorCount,
|
|
|
|
TRUE);
|
2024-06-06 20:19:04 +00:00
|
|
|
if (!NewPartEntry)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
|
|
|
DPRINT1("Failed to create a new empty region for extended partition space!\n");
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return;
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
LastStartSector = PartEntry->StartSector.QuadPart;
|
|
|
|
LastSectorCount = PartEntry->SectorCount.QuadPart;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for trailing unpartitioned disk space */
|
|
|
|
if ((LastStartSector + LastSectorCount) < DiskEntry->ExtendedPartition->StartSector.QuadPart + DiskEntry->ExtendedPartition->SectorCount.QuadPart)
|
|
|
|
{
|
2018-11-22 02:26:47 +00:00
|
|
|
LastUnusedSectorCount = AlignDown(DiskEntry->ExtendedPartition->StartSector.QuadPart +
|
|
|
|
DiskEntry->ExtendedPartition->SectorCount.QuadPart - (LastStartSector + LastSectorCount),
|
|
|
|
DiskEntry->SectorAlignment);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
if (LastUnusedSectorCount >= (ULONGLONG)DiskEntry->SectorAlignment)
|
|
|
|
{
|
|
|
|
DPRINT("Unpartitioned disk space: %I64u sectors\n", LastUnusedSectorCount);
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
StartSector = LastStartSector + LastSectorCount;
|
|
|
|
SectorCount = AlignDown(StartSector + LastUnusedSectorCount, DiskEntry->SectorAlignment) - StartSector;
|
|
|
|
|
|
|
|
/* Append the table to the list */
|
|
|
|
NewPartEntry = CreateInsertBlankRegion(DiskEntry,
|
|
|
|
&DiskEntry->LogicalPartListHead,
|
|
|
|
StartSector,
|
|
|
|
SectorCount,
|
|
|
|
TRUE);
|
2024-06-06 20:19:04 +00:00
|
|
|
if (!NewPartEntry)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
|
|
|
DPRINT1("Failed to create a new empty region for extended partition space!\n");
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return;
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
DPRINT("ScanForUnpartitionedDiskSpace() done\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
VOID
|
|
|
|
SetDiskSignature(
|
|
|
|
IN PPARTLIST List,
|
|
|
|
IN PDISKENTRY DiskEntry)
|
|
|
|
{
|
|
|
|
LARGE_INTEGER SystemTime;
|
|
|
|
TIME_FIELDS TimeFields;
|
|
|
|
PLIST_ENTRY Entry2;
|
|
|
|
PDISKENTRY DiskEntry2;
|
|
|
|
PUCHAR Buffer;
|
|
|
|
|
2018-12-13 23:30:12 +00:00
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
|
|
|
DPRINT("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Buffer = (PUCHAR)&DiskEntry->LayoutBuffer->Signature;
|
|
|
|
|
2017-05-21 23:34:03 +00:00
|
|
|
while (TRUE)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
NtQuerySystemTime(&SystemTime);
|
|
|
|
RtlTimeToTimeFields(&SystemTime, &TimeFields);
|
|
|
|
|
|
|
|
Buffer[0] = (UCHAR)(TimeFields.Year & 0xFF) + (UCHAR)(TimeFields.Hour & 0xFF);
|
|
|
|
Buffer[1] = (UCHAR)(TimeFields.Year >> 8) + (UCHAR)(TimeFields.Minute & 0xFF);
|
|
|
|
Buffer[2] = (UCHAR)(TimeFields.Month & 0xFF) + (UCHAR)(TimeFields.Second & 0xFF);
|
|
|
|
Buffer[3] = (UCHAR)(TimeFields.Day & 0xFF) + (UCHAR)(TimeFields.Milliseconds & 0xFF);
|
|
|
|
|
|
|
|
if (DiskEntry->LayoutBuffer->Signature == 0)
|
|
|
|
{
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-08-23 12:20:15 +00:00
|
|
|
/* Check if the signature already exist */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
/* FIXME:
|
|
|
|
* Check also signatures from disks, which are
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
* not visible (bootable) by the BIOS.
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
*/
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry2 = List->DiskListHead.Flink;
|
|
|
|
Entry2 != &List->DiskListHead;
|
|
|
|
Entry2 = Entry2->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
DiskEntry2 = CONTAINING_RECORD(Entry2, DISKENTRY, ListEntry);
|
|
|
|
|
2018-12-13 23:30:12 +00:00
|
|
|
if (DiskEntry2->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
|
|
|
DPRINT("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
if (DiskEntry != DiskEntry2 &&
|
|
|
|
DiskEntry->LayoutBuffer->Signature == DiskEntry2->LayoutBuffer->Signature)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Entry2 == &List->DiskListHead)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
VOID
|
|
|
|
UpdateDiskSignatures(
|
|
|
|
IN PPARTLIST List)
|
|
|
|
{
|
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
|
2018-12-13 23:30:12 +00:00
|
|
|
/* Update each disk */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry = List->DiskListHead.Flink;
|
|
|
|
Entry != &List->DiskListHead;
|
|
|
|
Entry = Entry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
DiskEntry = CONTAINING_RECORD(Entry, DISKENTRY, ListEntry);
|
|
|
|
|
2018-12-13 23:30:12 +00:00
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
|
|
|
DPRINT("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
if (DiskEntry->LayoutBuffer &&
|
|
|
|
DiskEntry->LayoutBuffer->Signature == 0)
|
|
|
|
{
|
|
|
|
SetDiskSignature(List, DiskEntry);
|
|
|
|
DiskEntry->LayoutBuffer->PartitionEntry[0].RewritePartition = TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
static
|
|
|
|
VOID
|
|
|
|
UpdateHwDiskNumbers(
|
|
|
|
IN PPARTLIST List)
|
|
|
|
{
|
|
|
|
PLIST_ENTRY ListEntry;
|
|
|
|
PBIOSDISKENTRY BiosDiskEntry;
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
ULONG HwAdapterNumber = 0;
|
|
|
|
ULONG HwControllerNumber = 0;
|
|
|
|
ULONG RemovableDiskCount = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Enumerate the disks recognized by the BIOS and recompute the disk
|
|
|
|
* numbers on the system when *ALL* removable disks are not connected.
|
|
|
|
* The entries are inserted in increasing order of AdapterNumber,
|
|
|
|
* ControllerNumber and DiskNumber.
|
|
|
|
*/
|
|
|
|
for (ListEntry = List->BiosDiskListHead.Flink;
|
|
|
|
ListEntry != &List->BiosDiskListHead;
|
|
|
|
ListEntry = ListEntry->Flink)
|
|
|
|
{
|
|
|
|
BiosDiskEntry = CONTAINING_RECORD(ListEntry, BIOSDISKENTRY, ListEntry);
|
|
|
|
DiskEntry = BiosDiskEntry->DiskEntry;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the adapter or controller numbers change, update them and reset
|
|
|
|
* the number of removable disks on this adapter/controller.
|
|
|
|
*/
|
|
|
|
if (HwAdapterNumber != BiosDiskEntry->AdapterNumber ||
|
|
|
|
HwControllerNumber != BiosDiskEntry->ControllerNumber)
|
|
|
|
{
|
|
|
|
HwAdapterNumber = BiosDiskEntry->AdapterNumber;
|
|
|
|
HwControllerNumber = BiosDiskEntry->ControllerNumber;
|
|
|
|
RemovableDiskCount = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Adjust the actual hardware disk number */
|
|
|
|
if (DiskEntry)
|
|
|
|
{
|
|
|
|
ASSERT(DiskEntry->HwDiskNumber == BiosDiskEntry->DiskNumber);
|
|
|
|
|
|
|
|
if (DiskEntry->MediaType == RemovableMedia)
|
|
|
|
{
|
|
|
|
/* Increase the number of removable disks and set the disk number to zero */
|
|
|
|
++RemovableDiskCount;
|
|
|
|
DiskEntry->HwFixedDiskNumber = 0;
|
|
|
|
}
|
|
|
|
else // if (DiskEntry->MediaType == FixedMedia)
|
|
|
|
{
|
|
|
|
/* Adjust the fixed disk number, offset by the number of removable disks found before this one */
|
|
|
|
DiskEntry->HwFixedDiskNumber = BiosDiskEntry->DiskNumber - RemovableDiskCount;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
DPRINT1("BIOS disk %lu is not recognized by NTOS!\n", BiosDiskEntry->DiskNumber);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
static
|
|
|
|
VOID
|
|
|
|
AddDiskToList(
|
|
|
|
IN HANDLE FileHandle,
|
|
|
|
IN ULONG DiskNumber,
|
|
|
|
IN PPARTLIST List)
|
|
|
|
{
|
|
|
|
DISK_GEOMETRY DiskGeometry;
|
|
|
|
SCSI_ADDRESS ScsiAddress;
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
IO_STATUS_BLOCK Iosb;
|
|
|
|
NTSTATUS Status;
|
|
|
|
PPARTITION_SECTOR Mbr;
|
|
|
|
PULONG Buffer;
|
|
|
|
LARGE_INTEGER FileOffset;
|
|
|
|
WCHAR Identifier[20];
|
|
|
|
ULONG Checksum;
|
|
|
|
ULONG Signature;
|
|
|
|
ULONG i;
|
|
|
|
PLIST_ENTRY ListEntry;
|
|
|
|
PBIOSDISKENTRY BiosDiskEntry;
|
|
|
|
ULONG LayoutBufferSize;
|
|
|
|
PDRIVE_LAYOUT_INFORMATION NewLayoutBuffer;
|
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
/* Retrieve the drive geometry */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = NtDeviceIoControlFile(FileHandle,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
&Iosb,
|
|
|
|
IOCTL_DISK_GET_DRIVE_GEOMETRY,
|
|
|
|
NULL,
|
|
|
|
0,
|
|
|
|
&DiskGeometry,
|
2018-01-28 22:24:06 +00:00
|
|
|
sizeof(DiskGeometry));
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (DiskGeometry.MediaType != FixedMedia &&
|
|
|
|
DiskGeometry.MediaType != RemovableMedia)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
/*
|
|
|
|
* FIXME: Here we suppose the disk is always SCSI. What if it is
|
|
|
|
* of another type? To check this we need to retrieve the name of
|
|
|
|
* the driver the disk device belongs to.
|
|
|
|
*/
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = NtDeviceIoControlFile(FileHandle,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
&Iosb,
|
|
|
|
IOCTL_SCSI_GET_ADDRESS,
|
|
|
|
NULL,
|
|
|
|
0,
|
|
|
|
&ScsiAddress,
|
2018-01-28 22:24:06 +00:00
|
|
|
sizeof(ScsiAddress));
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether the disk is initialized, by looking at its MBR.
|
|
|
|
* NOTE that this must be generalized to GPT disks as well!
|
|
|
|
*/
|
|
|
|
|
|
|
|
Mbr = (PARTITION_SECTOR*)RtlAllocateHeap(ProcessHeap,
|
|
|
|
0,
|
|
|
|
DiskGeometry.BytesPerSector);
|
|
|
|
if (Mbr == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
FileOffset.QuadPart = 0;
|
|
|
|
Status = NtReadFile(FileHandle,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
&Iosb,
|
|
|
|
(PVOID)Mbr,
|
|
|
|
DiskGeometry.BytesPerSector,
|
|
|
|
&FileOffset,
|
|
|
|
NULL);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, Mbr);
|
|
|
|
DPRINT1("NtReadFile failed, status=%x\n", Status);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
Signature = Mbr->Signature;
|
|
|
|
|
|
|
|
/* Calculate the MBR checksum */
|
|
|
|
Checksum = 0;
|
|
|
|
Buffer = (PULONG)Mbr;
|
|
|
|
for (i = 0; i < 128; i++)
|
|
|
|
{
|
|
|
|
Checksum += Buffer[i];
|
|
|
|
}
|
|
|
|
Checksum = ~Checksum + 1;
|
|
|
|
|
2017-05-31 01:43:12 +00:00
|
|
|
RtlStringCchPrintfW(Identifier, ARRAYSIZE(Identifier),
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
L"%08x-%08x-%c",
|
|
|
|
Checksum, Signature,
|
|
|
|
(Mbr->Magic == PARTITION_MAGIC) ? L'A' : L'X');
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
DPRINT("Identifier: %S\n", Identifier);
|
|
|
|
|
|
|
|
DiskEntry = RtlAllocateHeap(ProcessHeap,
|
|
|
|
HEAP_ZERO_MEMORY,
|
|
|
|
sizeof(DISKENTRY));
|
|
|
|
if (DiskEntry == NULL)
|
|
|
|
{
|
2018-01-28 22:24:06 +00:00
|
|
|
RtlFreeHeap(ProcessHeap, 0, Mbr);
|
|
|
|
DPRINT1("Failed to allocate a new disk entry.\n");
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
DiskEntry->PartList = List;
|
|
|
|
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
#if 0
|
|
|
|
{
|
|
|
|
FILE_FS_DEVICE_INFORMATION FileFsDevice;
|
|
|
|
|
|
|
|
/* Query the device for its type */
|
|
|
|
Status = NtQueryVolumeInformationFile(FileHandle,
|
|
|
|
&Iosb,
|
|
|
|
&FileFsDevice,
|
|
|
|
sizeof(FileFsDevice),
|
|
|
|
FileFsDeviceInformation);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("Couldn't detect device type for disk %lu of identifier '%S'...\n", DiskNumber, Identifier);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
DPRINT1("Disk %lu : DeviceType: 0x%08x ; Characteristics: 0x%08x\n", DiskNumber, FileFsDevice.DeviceType, FileFsDevice.Characteristics);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// NOTE: We may also use NtQueryVolumeInformationFile(FileFsDeviceInformation).
|
|
|
|
#endif
|
|
|
|
DiskEntry->MediaType = DiskGeometry.MediaType;
|
|
|
|
if (DiskEntry->MediaType == RemovableMedia)
|
|
|
|
{
|
|
|
|
DPRINT1("Disk %lu of identifier '%S' is removable\n", DiskNumber, Identifier);
|
|
|
|
}
|
|
|
|
else // if (DiskEntry->MediaType == FixedMedia)
|
|
|
|
{
|
|
|
|
DPRINT1("Disk %lu of identifier '%S' is fixed\n", DiskNumber, Identifier);
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
// DiskEntry->Checksum = Checksum;
|
|
|
|
// DiskEntry->Signature = Signature;
|
|
|
|
DiskEntry->BiosFound = FALSE;
|
|
|
|
|
2017-05-31 01:11:05 +00:00
|
|
|
/*
|
|
|
|
* Check if this disk has a valid MBR: verify its signature,
|
|
|
|
* and whether its two first bytes are a valid instruction
|
|
|
|
* (related to this, see IsThereAValidBootSector() in partlist.c).
|
2018-12-13 23:30:12 +00:00
|
|
|
*
|
|
|
|
* See also ntoskrnl/fstub/fstubex.c!FstubDetectPartitionStyle().
|
2017-05-31 01:11:05 +00:00
|
|
|
*/
|
2018-12-13 23:30:12 +00:00
|
|
|
|
|
|
|
// DiskEntry->NoMbr = (Mbr->Magic != PARTITION_MAGIC || (*(PUSHORT)Mbr->BootCode) == 0x0000);
|
|
|
|
|
|
|
|
/* If we have not the 0xAA55 then it's raw partition */
|
|
|
|
if (Mbr->Magic != PARTITION_MAGIC)
|
|
|
|
{
|
|
|
|
DiskEntry->DiskStyle = PARTITION_STYLE_RAW;
|
|
|
|
}
|
|
|
|
/* Check partitions types: if first is 0xEE and all the others 0, we have GPT */
|
|
|
|
else if (Mbr->Partition[0].PartitionType == EFI_PMBR_OSTYPE_EFI &&
|
|
|
|
Mbr->Partition[1].PartitionType == 0 &&
|
|
|
|
Mbr->Partition[2].PartitionType == 0 &&
|
|
|
|
Mbr->Partition[3].PartitionType == 0)
|
|
|
|
{
|
|
|
|
DiskEntry->DiskStyle = PARTITION_STYLE_GPT;
|
|
|
|
}
|
|
|
|
/* Otherwise, partition table is in MBR */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
else
|
2018-12-13 23:30:12 +00:00
|
|
|
{
|
|
|
|
DiskEntry->DiskStyle = PARTITION_STYLE_MBR;
|
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
/* Free the MBR sector buffer */
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, Mbr);
|
|
|
|
|
|
|
|
|
2018-12-08 23:36:56 +00:00
|
|
|
for (ListEntry = List->BiosDiskListHead.Flink;
|
|
|
|
ListEntry != &List->BiosDiskListHead;
|
|
|
|
ListEntry = ListEntry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
BiosDiskEntry = CONTAINING_RECORD(ListEntry, BIOSDISKENTRY, ListEntry);
|
|
|
|
/* FIXME:
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
* Compare the size from BIOS and the reported size from driver.
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
* If we have more than one disk with a zero or with the same signature
|
|
|
|
* we must create new signatures and reboot. After the reboot,
|
|
|
|
* it is possible to identify the disks.
|
|
|
|
*/
|
|
|
|
if (BiosDiskEntry->Signature == Signature &&
|
|
|
|
BiosDiskEntry->Checksum == Checksum &&
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
BiosDiskEntry->DiskEntry == NULL)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
if (!DiskEntry->BiosFound)
|
|
|
|
{
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
DiskEntry->HwAdapterNumber = BiosDiskEntry->AdapterNumber;
|
|
|
|
DiskEntry->HwControllerNumber = BiosDiskEntry->ControllerNumber;
|
|
|
|
DiskEntry->HwDiskNumber = BiosDiskEntry->DiskNumber;
|
|
|
|
|
|
|
|
if (DiskEntry->MediaType == RemovableMedia)
|
|
|
|
{
|
|
|
|
/* Set the removable disk number to zero */
|
|
|
|
DiskEntry->HwFixedDiskNumber = 0;
|
|
|
|
}
|
|
|
|
else // if (DiskEntry->MediaType == FixedMedia)
|
|
|
|
{
|
|
|
|
/* The fixed disk number will later be adjusted using the number of removable disks */
|
|
|
|
DiskEntry->HwFixedDiskNumber = BiosDiskEntry->DiskNumber;
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
DiskEntry->BiosFound = TRUE;
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
BiosDiskEntry->DiskEntry = DiskEntry;
|
|
|
|
break;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-01-28 22:24:06 +00:00
|
|
|
// FIXME: What to do?
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
DPRINT1("Disk %lu of identifier '%S' has already been found?!\n", DiskNumber, Identifier);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!DiskEntry->BiosFound)
|
|
|
|
{
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
DPRINT1("WARNING: Setup could not find a matching BIOS disk entry. Disk %lu may not be bootable by the BIOS!\n", DiskNumber);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DiskEntry->Cylinders = DiskGeometry.Cylinders.QuadPart;
|
|
|
|
DiskEntry->TracksPerCylinder = DiskGeometry.TracksPerCylinder;
|
|
|
|
DiskEntry->SectorsPerTrack = DiskGeometry.SectorsPerTrack;
|
|
|
|
DiskEntry->BytesPerSector = DiskGeometry.BytesPerSector;
|
|
|
|
|
|
|
|
DPRINT("Cylinders %I64u\n", DiskEntry->Cylinders);
|
|
|
|
DPRINT("TracksPerCylinder %lu\n", DiskEntry->TracksPerCylinder);
|
|
|
|
DPRINT("SectorsPerTrack %lu\n", DiskEntry->SectorsPerTrack);
|
|
|
|
DPRINT("BytesPerSector %lu\n", DiskEntry->BytesPerSector);
|
|
|
|
|
|
|
|
DiskEntry->SectorCount.QuadPart = DiskGeometry.Cylinders.QuadPart *
|
|
|
|
(ULONGLONG)DiskGeometry.TracksPerCylinder *
|
|
|
|
(ULONGLONG)DiskGeometry.SectorsPerTrack;
|
|
|
|
|
|
|
|
DiskEntry->SectorAlignment = DiskGeometry.SectorsPerTrack;
|
|
|
|
DiskEntry->CylinderAlignment = DiskGeometry.TracksPerCylinder *
|
|
|
|
DiskGeometry.SectorsPerTrack;
|
|
|
|
|
|
|
|
DPRINT("SectorCount %I64u\n", DiskEntry->SectorCount.QuadPart);
|
|
|
|
DPRINT("SectorAlignment %lu\n", DiskEntry->SectorAlignment);
|
|
|
|
|
|
|
|
DiskEntry->DiskNumber = DiskNumber;
|
|
|
|
DiskEntry->Port = ScsiAddress.PortNumber;
|
|
|
|
DiskEntry->Bus = ScsiAddress.PathId;
|
|
|
|
DiskEntry->Id = ScsiAddress.TargetId;
|
|
|
|
|
|
|
|
GetDriverName(DiskEntry);
|
2017-05-21 23:36:13 +00:00
|
|
|
/*
|
|
|
|
* Actually it would be more correct somehow to use:
|
|
|
|
*
|
|
|
|
* OBJECT_NAME_INFORMATION NameInfo; // ObjectNameInfo;
|
|
|
|
* ULONG ReturnedLength;
|
|
|
|
*
|
|
|
|
* Status = NtQueryObject(SomeHandleToTheDisk,
|
|
|
|
* ObjectNameInformation,
|
|
|
|
* &NameInfo,
|
|
|
|
* sizeof(NameInfo),
|
|
|
|
* &ReturnedLength);
|
|
|
|
* etc...
|
|
|
|
*
|
|
|
|
* See examples in https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/ntoskrnl/io/iomgr/error.c;hb=2f3a93ee9cec8322a86bf74b356f1ad83fc912dc#l267
|
|
|
|
*/
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
InitializeListHead(&DiskEntry->PrimaryPartListHead);
|
|
|
|
InitializeListHead(&DiskEntry->LogicalPartListHead);
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
InsertAscendingList(&List->DiskListHead, DiskEntry, DISKENTRY, ListEntry, DiskNumber);
|
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We now retrieve the disk partition layout
|
|
|
|
*/
|
|
|
|
|
2018-12-13 23:30:12 +00:00
|
|
|
/*
|
|
|
|
* Stop there now if the disk is GPT-partitioned,
|
|
|
|
* since we currently do not support such disks.
|
|
|
|
*/
|
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
|
|
|
DPRINT1("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
/* Allocate a layout buffer with 4 partition entries first */
|
|
|
|
LayoutBufferSize = sizeof(DRIVE_LAYOUT_INFORMATION) +
|
|
|
|
((4 - ANYSIZE_ARRAY) * sizeof(PARTITION_INFORMATION));
|
|
|
|
DiskEntry->LayoutBuffer = RtlAllocateHeap(ProcessHeap,
|
|
|
|
HEAP_ZERO_MEMORY,
|
|
|
|
LayoutBufferSize);
|
|
|
|
if (DiskEntry->LayoutBuffer == NULL)
|
|
|
|
{
|
|
|
|
DPRINT1("Failed to allocate the disk layout buffer!\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
/* Keep looping while the drive layout buffer is too small */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
DPRINT1("Buffer size: %lu\n", LayoutBufferSize);
|
|
|
|
Status = NtDeviceIoControlFile(FileHandle,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
&Iosb,
|
|
|
|
IOCTL_DISK_GET_DRIVE_LAYOUT,
|
|
|
|
NULL,
|
|
|
|
0,
|
|
|
|
DiskEntry->LayoutBuffer,
|
|
|
|
LayoutBufferSize);
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (Status != STATUS_BUFFER_TOO_SMALL)
|
|
|
|
{
|
|
|
|
DPRINT1("NtDeviceIoControlFile() failed (Status: 0x%08lx)\n", Status);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
LayoutBufferSize += 4 * sizeof(PARTITION_INFORMATION);
|
|
|
|
NewLayoutBuffer = RtlReAllocateHeap(ProcessHeap,
|
|
|
|
HEAP_ZERO_MEMORY,
|
|
|
|
DiskEntry->LayoutBuffer,
|
|
|
|
LayoutBufferSize);
|
|
|
|
if (NewLayoutBuffer == NULL)
|
|
|
|
{
|
|
|
|
DPRINT1("Failed to reallocate the disk layout buffer!\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
DiskEntry->LayoutBuffer = NewLayoutBuffer;
|
|
|
|
}
|
|
|
|
|
|
|
|
DPRINT1("PartitionCount: %lu\n", DiskEntry->LayoutBuffer->PartitionCount);
|
|
|
|
|
|
|
|
#ifdef DUMP_PARTITION_TABLE
|
|
|
|
DumpPartitionTable(DiskEntry);
|
|
|
|
#endif
|
|
|
|
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
if (IsSuperFloppy(DiskEntry))
|
|
|
|
DPRINT1("Disk %lu is a super-floppy\n", DiskNumber);
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
if (DiskEntry->LayoutBuffer->PartitionEntry[0].StartingOffset.QuadPart != 0 &&
|
|
|
|
DiskEntry->LayoutBuffer->PartitionEntry[0].PartitionLength.QuadPart != 0 &&
|
|
|
|
DiskEntry->LayoutBuffer->PartitionEntry[0].PartitionType != PARTITION_ENTRY_UNUSED)
|
|
|
|
{
|
|
|
|
if ((DiskEntry->LayoutBuffer->PartitionEntry[0].StartingOffset.QuadPart / DiskEntry->BytesPerSector) % DiskEntry->SectorsPerTrack == 0)
|
|
|
|
{
|
|
|
|
DPRINT("Use %lu Sector alignment!\n", DiskEntry->SectorsPerTrack);
|
|
|
|
}
|
|
|
|
else if (DiskEntry->LayoutBuffer->PartitionEntry[0].StartingOffset.QuadPart % (1024 * 1024) == 0)
|
|
|
|
{
|
|
|
|
DPRINT1("Use megabyte (%lu Sectors) alignment!\n", (1024 * 1024) / DiskEntry->BytesPerSector);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
DPRINT1("No matching alignment found! Partition 1 starts at %I64u\n", DiskEntry->LayoutBuffer->PartitionEntry[0].StartingOffset.QuadPart);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
DPRINT1("No valid partition table found! Use megabyte (%lu Sectors) alignment!\n", (1024 * 1024) / DiskEntry->BytesPerSector);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (DiskEntry->LayoutBuffer->PartitionCount == 0)
|
|
|
|
{
|
|
|
|
DiskEntry->NewDisk = TRUE;
|
|
|
|
DiskEntry->LayoutBuffer->PartitionCount = 4;
|
|
|
|
|
|
|
|
for (i = 0; i < 4; i++)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
DiskEntry->LayoutBuffer->PartitionEntry[i].RewritePartition = TRUE;
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-11-22 02:26:47 +00:00
|
|
|
/* Enumerate and add the first four primary partitions */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
for (i = 0; i < 4; i++)
|
|
|
|
{
|
|
|
|
AddPartitionToDisk(DiskNumber, DiskEntry, i, FALSE);
|
|
|
|
}
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
/* Enumerate and add the remaining partitions as logical ones */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
for (i = 4; i < DiskEntry->LayoutBuffer->PartitionCount; i += 4)
|
|
|
|
{
|
|
|
|
AddPartitionToDisk(DiskNumber, DiskEntry, i, TRUE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ScanForUnpartitionedDiskSpace(DiskEntry);
|
|
|
|
}
|
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/*
|
|
|
|
* Retrieve the system disk, i.e. the fixed disk that is accessible by the
|
|
|
|
* firmware during boot time and where the system partition resides.
|
|
|
|
* If no system partition has been determined, we retrieve the first disk
|
|
|
|
* that verifies the mentioned criteria above.
|
|
|
|
*/
|
|
|
|
static
|
|
|
|
PDISKENTRY
|
|
|
|
GetSystemDisk(
|
|
|
|
IN PPARTLIST List)
|
|
|
|
{
|
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
|
|
|
|
/* Check for empty disk list */
|
|
|
|
if (IsListEmpty(&List->DiskListHead))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we already have a system partition, the system disk
|
|
|
|
* is the one on which the system partition resides.
|
|
|
|
*/
|
|
|
|
if (List->SystemPartition)
|
|
|
|
return List->SystemPartition->DiskEntry;
|
|
|
|
|
|
|
|
/* Loop over the disks and find the correct one */
|
|
|
|
for (Entry = List->DiskListHead.Flink;
|
|
|
|
Entry != &List->DiskListHead;
|
|
|
|
Entry = Entry->Flink)
|
|
|
|
{
|
|
|
|
DiskEntry = CONTAINING_RECORD(Entry, DISKENTRY, ListEntry);
|
|
|
|
|
|
|
|
/* The disk must be a fixed disk and be found by the firmware */
|
|
|
|
if (DiskEntry->MediaType == FixedMedia && DiskEntry->BiosFound)
|
|
|
|
{
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (Entry == &List->DiskListHead)
|
|
|
|
{
|
|
|
|
/* We haven't encountered any suitable disk */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
|
|
|
DPRINT1("System disk -- GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
return DiskEntry;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Retrieve the actual "active" partition of the given disk.
|
|
|
|
* On MBR disks, partition with the Active/Boot flag set;
|
|
|
|
* on GPT disks, partition with the correct GUID.
|
|
|
|
*/
|
|
|
|
BOOLEAN
|
|
|
|
IsPartitionActive(
|
|
|
|
IN PPARTENTRY PartEntry)
|
|
|
|
{
|
|
|
|
// TODO: Support for GPT disks!
|
|
|
|
|
|
|
|
if (IsContainerPartition(PartEntry->PartitionType))
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
/* Check if the partition is partitioned, used and active */
|
|
|
|
if (PartEntry->IsPartitioned &&
|
|
|
|
// !IsContainerPartition(PartEntry->PartitionType) &&
|
|
|
|
PartEntry->BootIndicator)
|
|
|
|
{
|
|
|
|
/* Yes it is */
|
|
|
|
ASSERT(PartEntry->PartitionType != PARTITION_ENTRY_UNUSED);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
PPARTENTRY
|
|
|
|
GetActiveDiskPartition(
|
|
|
|
IN PDISKENTRY DiskEntry)
|
|
|
|
{
|
|
|
|
PLIST_ENTRY ListEntry;
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
PPARTENTRY ActivePartition = NULL;
|
|
|
|
|
|
|
|
/* Check for empty disk list */
|
|
|
|
// ASSERT(DiskEntry);
|
|
|
|
if (!DiskEntry)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* Check for empty partition list */
|
|
|
|
if (IsListEmpty(&DiskEntry->PrimaryPartListHead))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
|
|
|
DPRINT1("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Scan all (primary) partitions to find the active disk partition */
|
|
|
|
for (ListEntry = DiskEntry->PrimaryPartListHead.Flink;
|
|
|
|
ListEntry != &DiskEntry->PrimaryPartListHead;
|
|
|
|
ListEntry = ListEntry->Flink)
|
|
|
|
{
|
|
|
|
/* Retrieve the partition */
|
|
|
|
PartEntry = CONTAINING_RECORD(ListEntry, PARTENTRY, ListEntry);
|
|
|
|
if (IsPartitionActive(PartEntry))
|
|
|
|
{
|
|
|
|
/* Yes, we've found it */
|
|
|
|
ASSERT(DiskEntry == PartEntry->DiskEntry);
|
|
|
|
ASSERT(PartEntry->IsPartitioned);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
ASSERT(PartEntry->Volume);
|
2019-08-25 00:08:23 +00:00
|
|
|
|
|
|
|
ActivePartition = PartEntry;
|
|
|
|
|
|
|
|
DPRINT1("Found active system partition %lu in disk %lu, drive letter %C\n",
|
|
|
|
PartEntry->PartitionNumber, DiskEntry->DiskNumber,
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
!PartEntry->Volume->Info.DriveLetter ? L'-' : PartEntry->Volume->Info.DriveLetter);
|
2019-08-25 00:08:23 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if the disk is new and if so, use its first partition as the active system partition */
|
|
|
|
if (DiskEntry->NewDisk && ActivePartition != NULL)
|
|
|
|
{
|
|
|
|
// FIXME: What to do??
|
|
|
|
DPRINT1("NewDisk TRUE but already existing active partition?\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the active partition found (or none) */
|
|
|
|
return ActivePartition;
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PPARTLIST
|
|
|
|
CreatePartitionList(VOID)
|
|
|
|
{
|
|
|
|
PPARTLIST List;
|
2019-08-25 00:08:23 +00:00
|
|
|
PDISKENTRY SystemDisk;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
|
|
|
SYSTEM_DEVICE_INFORMATION Sdi;
|
|
|
|
IO_STATUS_BLOCK Iosb;
|
|
|
|
ULONG ReturnSize;
|
|
|
|
NTSTATUS Status;
|
|
|
|
ULONG DiskNumber;
|
|
|
|
HANDLE FileHandle;
|
2019-08-24 23:32:46 +00:00
|
|
|
UNICODE_STRING Name;
|
|
|
|
WCHAR Buffer[MAX_PATH];
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
List = (PPARTLIST)RtlAllocateHeap(ProcessHeap,
|
|
|
|
0,
|
2017-05-31 01:43:12 +00:00
|
|
|
sizeof(PARTLIST));
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!List)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
List->SystemPartition = NULL;
|
|
|
|
|
|
|
|
InitializeListHead(&List->DiskListHead);
|
|
|
|
InitializeListHead(&List->BiosDiskListHead);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
InitializeListHead(&List->VolumesList);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
/*
|
|
|
|
* Enumerate the disks seen by the BIOS; this will be used later
|
|
|
|
* to map drives seen by NTOS with their corresponding BIOS names.
|
|
|
|
*/
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
EnumerateBiosDiskEntries(List);
|
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
/* Enumerate disks seen by NTOS */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = NtQuerySystemInformation(SystemDeviceInformation,
|
|
|
|
&Sdi,
|
|
|
|
sizeof(Sdi),
|
|
|
|
&ReturnSize);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
2023-11-16 22:22:12 +00:00
|
|
|
DPRINT1("NtQuerySystemInformation() failed, Status 0x%08lx\n", Status);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
RtlFreeHeap(ProcessHeap, 0, List);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (DiskNumber = 0; DiskNumber < Sdi.NumberOfDisks; DiskNumber++)
|
|
|
|
{
|
2017-05-31 01:43:12 +00:00
|
|
|
RtlStringCchPrintfW(Buffer, ARRAYSIZE(Buffer),
|
|
|
|
L"\\Device\\Harddisk%lu\\Partition0",
|
|
|
|
DiskNumber);
|
|
|
|
RtlInitUnicodeString(&Name, Buffer);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&Name,
|
2017-12-23 19:17:38 +00:00
|
|
|
OBJ_CASE_INSENSITIVE,
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
Status = NtOpenFile(&FileHandle,
|
|
|
|
FILE_READ_DATA | FILE_READ_ATTRIBUTES | SYNCHRONIZE,
|
|
|
|
&ObjectAttributes,
|
|
|
|
&Iosb,
|
2018-01-28 22:24:06 +00:00
|
|
|
FILE_SHARE_READ | FILE_SHARE_WRITE,
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
FILE_SYNCHRONOUS_IO_NONALERT);
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
AddDiskToList(FileHandle, DiskNumber, List);
|
|
|
|
NtClose(FileHandle);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
UpdateDiskSignatures(List);
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
UpdateHwDiskNumbers(List);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
AssignDriveLetters(List);
|
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/*
|
|
|
|
* Retrieve the system partition: the active partition on the system
|
|
|
|
* disk (the one that will be booted by default by the hardware).
|
|
|
|
*/
|
|
|
|
SystemDisk = GetSystemDisk(List);
|
|
|
|
List->SystemPartition = (SystemDisk ? GetActiveDiskPartition(SystemDisk) : NULL);
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return List;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
DestroyPartitionList(
|
|
|
|
IN PPARTLIST List)
|
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
PBIOSDISKENTRY BiosDiskEntry;
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
|
|
|
|
/* Release disk and partition info */
|
|
|
|
while (!IsListEmpty(&List->DiskListHead))
|
|
|
|
{
|
|
|
|
Entry = RemoveHeadList(&List->DiskListHead);
|
|
|
|
DiskEntry = CONTAINING_RECORD(Entry, DISKENTRY, ListEntry);
|
|
|
|
|
|
|
|
/* Release driver name */
|
|
|
|
RtlFreeUnicodeString(&DiskEntry->DriverName);
|
|
|
|
|
|
|
|
/* Release primary partition list */
|
|
|
|
while (!IsListEmpty(&DiskEntry->PrimaryPartListHead))
|
|
|
|
{
|
|
|
|
Entry = RemoveHeadList(&DiskEntry->PrimaryPartListHead);
|
|
|
|
PartEntry = CONTAINING_RECORD(Entry, PARTENTRY, ListEntry);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
DestroyRegion(PartEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Release logical partition list */
|
|
|
|
while (!IsListEmpty(&DiskEntry->LogicalPartListHead))
|
|
|
|
{
|
|
|
|
Entry = RemoveHeadList(&DiskEntry->LogicalPartListHead);
|
|
|
|
PartEntry = CONTAINING_RECORD(Entry, PARTENTRY, ListEntry);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
DestroyRegion(PartEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Release layout buffer */
|
|
|
|
if (DiskEntry->LayoutBuffer != NULL)
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, DiskEntry->LayoutBuffer);
|
|
|
|
|
|
|
|
/* Release disk entry */
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, DiskEntry);
|
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Release the BIOS disk info */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
while (!IsListEmpty(&List->BiosDiskListHead))
|
|
|
|
{
|
|
|
|
Entry = RemoveHeadList(&List->BiosDiskListHead);
|
|
|
|
BiosDiskEntry = CONTAINING_RECORD(Entry, BIOSDISKENTRY, ListEntry);
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, BiosDiskEntry);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Release list head */
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, List);
|
|
|
|
}
|
|
|
|
|
2017-05-21 23:36:13 +00:00
|
|
|
PDISKENTRY
|
|
|
|
GetDiskByBiosNumber(
|
2024-06-20 20:36:16 +00:00
|
|
|
_In_ PPARTLIST List,
|
|
|
|
_In_ ULONG HwDiskNumber)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry;
|
2017-05-21 23:36:13 +00:00
|
|
|
PLIST_ENTRY Entry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2017-05-21 23:36:13 +00:00
|
|
|
/* Loop over the disks and find the correct one */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry = List->DiskListHead.Flink;
|
|
|
|
Entry != &List->DiskListHead;
|
|
|
|
Entry = Entry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2017-05-21 23:36:13 +00:00
|
|
|
DiskEntry = CONTAINING_RECORD(Entry, DISKENTRY, ListEntry);
|
|
|
|
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
if (DiskEntry->HwDiskNumber == HwDiskNumber)
|
2024-06-20 20:36:16 +00:00
|
|
|
return DiskEntry; /* Disk found, return it */
|
2017-05-21 23:36:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Disk not found, stop there */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
PDISKENTRY
|
|
|
|
GetDiskByNumber(
|
2024-06-20 20:36:16 +00:00
|
|
|
_In_ PPARTLIST List,
|
|
|
|
_In_ ULONG DiskNumber)
|
2017-05-21 23:36:13 +00:00
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
|
|
|
|
/* Loop over the disks and find the correct one */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry = List->DiskListHead.Flink;
|
|
|
|
Entry != &List->DiskListHead;
|
|
|
|
Entry = Entry->Flink)
|
2017-05-21 23:36:13 +00:00
|
|
|
{
|
|
|
|
DiskEntry = CONTAINING_RECORD(Entry, DISKENTRY, ListEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
if (DiskEntry->DiskNumber == DiskNumber)
|
2024-06-20 20:36:16 +00:00
|
|
|
return DiskEntry; /* Disk found, return it */
|
2017-05-21 23:36:13 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2017-05-21 23:36:13 +00:00
|
|
|
/* Disk not found, stop there */
|
|
|
|
return NULL;
|
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2017-05-21 23:36:13 +00:00
|
|
|
PDISKENTRY
|
|
|
|
GetDiskBySCSI(
|
2024-06-20 20:36:16 +00:00
|
|
|
_In_ PPARTLIST List,
|
|
|
|
_In_ USHORT Port,
|
|
|
|
_In_ USHORT Bus,
|
|
|
|
_In_ USHORT Id)
|
2017-05-21 23:36:13 +00:00
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
PLIST_ENTRY Entry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2017-05-21 23:36:13 +00:00
|
|
|
/* Loop over the disks and find the correct one */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry = List->DiskListHead.Flink;
|
|
|
|
Entry != &List->DiskListHead;
|
|
|
|
Entry = Entry->Flink)
|
2017-05-21 23:36:13 +00:00
|
|
|
{
|
|
|
|
DiskEntry = CONTAINING_RECORD(Entry, DISKENTRY, ListEntry);
|
|
|
|
|
|
|
|
if (DiskEntry->Port == Port &&
|
|
|
|
DiskEntry->Bus == Bus &&
|
|
|
|
DiskEntry->Id == Id)
|
|
|
|
{
|
2024-06-20 20:36:16 +00:00
|
|
|
/* Disk found, return it */
|
2017-05-21 23:36:13 +00:00
|
|
|
return DiskEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
2017-05-21 23:36:13 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2017-05-21 23:36:13 +00:00
|
|
|
/* Disk not found, stop there */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
PDISKENTRY
|
|
|
|
GetDiskBySignature(
|
2024-06-20 20:36:16 +00:00
|
|
|
_In_ PPARTLIST List,
|
|
|
|
_In_ ULONG Signature)
|
2017-05-21 23:36:13 +00:00
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
|
|
|
|
/* Loop over the disks and find the correct one */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry = List->DiskListHead.Flink;
|
|
|
|
Entry != &List->DiskListHead;
|
|
|
|
Entry = Entry->Flink)
|
2017-05-21 23:36:13 +00:00
|
|
|
{
|
|
|
|
DiskEntry = CONTAINING_RECORD(Entry, DISKENTRY, ListEntry);
|
|
|
|
|
|
|
|
if (DiskEntry->LayoutBuffer->Signature == Signature)
|
2024-06-20 20:36:16 +00:00
|
|
|
return DiskEntry; /* Disk found, return it */
|
2017-05-21 23:36:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Disk not found, stop there */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
PPARTENTRY
|
|
|
|
GetPartition(
|
2024-06-20 20:36:16 +00:00
|
|
|
_In_ PDISKENTRY DiskEntry,
|
|
|
|
_In_ ULONG PartitionNumber)
|
2017-05-21 23:36:13 +00:00
|
|
|
{
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
|
2024-07-02 11:48:58 +00:00
|
|
|
/* Forbid whole-disk or extended container partition access */
|
|
|
|
if (PartitionNumber == 0)
|
|
|
|
return NULL;
|
|
|
|
|
2024-06-20 20:36:16 +00:00
|
|
|
/* Loop over the primary partitions first... */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry = DiskEntry->PrimaryPartListHead.Flink;
|
|
|
|
Entry != &DiskEntry->PrimaryPartListHead;
|
|
|
|
Entry = Entry->Flink)
|
2017-05-21 23:36:13 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(Entry, PARTENTRY, ListEntry);
|
|
|
|
|
|
|
|
if (PartEntry->PartitionNumber == PartitionNumber)
|
2024-06-20 20:36:16 +00:00
|
|
|
return PartEntry; /* Partition found, return it */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
2024-06-20 20:36:16 +00:00
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
return NULL;
|
|
|
|
|
2017-05-21 23:36:13 +00:00
|
|
|
/* ... then over the logical partitions if needed */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry = DiskEntry->LogicalPartListHead.Flink;
|
|
|
|
Entry != &DiskEntry->LogicalPartListHead;
|
|
|
|
Entry = Entry->Flink)
|
2017-05-21 23:36:13 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(Entry, PARTENTRY, ListEntry);
|
|
|
|
|
|
|
|
if (PartEntry->PartitionNumber == PartitionNumber)
|
2024-06-20 20:36:16 +00:00
|
|
|
return PartEntry; /* Partition found, return it */
|
2017-05-21 23:36:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* The partition was not found on the disk, stop there */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
PPARTENTRY
|
2017-05-21 23:36:13 +00:00
|
|
|
SelectPartition(
|
2024-06-20 20:36:16 +00:00
|
|
|
_In_ PPARTLIST List,
|
|
|
|
_In_ ULONG DiskNumber,
|
|
|
|
_In_ ULONG PartitionNumber)
|
2017-05-21 23:36:13 +00:00
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
|
2024-06-20 20:36:16 +00:00
|
|
|
/* Find the disk */
|
2017-05-21 23:36:13 +00:00
|
|
|
DiskEntry = GetDiskByNumber(List, DiskNumber);
|
|
|
|
if (!DiskEntry)
|
2019-03-05 00:42:33 +00:00
|
|
|
return NULL;
|
2024-06-20 20:36:16 +00:00
|
|
|
ASSERT(DiskEntry->DiskNumber == DiskNumber);
|
2017-05-21 23:36:13 +00:00
|
|
|
|
2024-06-20 20:36:16 +00:00
|
|
|
/* Find the partition */
|
|
|
|
PartEntry = GetPartition(DiskEntry, PartitionNumber);
|
2017-05-21 23:36:13 +00:00
|
|
|
if (!PartEntry)
|
2019-03-05 00:42:33 +00:00
|
|
|
return NULL;
|
2017-05-21 23:36:13 +00:00
|
|
|
ASSERT(PartEntry->DiskEntry == DiskEntry);
|
|
|
|
ASSERT(PartEntry->PartitionNumber == PartitionNumber);
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
return PartEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
PPARTENTRY
|
|
|
|
GetNextPartition(
|
2019-03-05 00:42:33 +00:00
|
|
|
IN PPARTLIST List,
|
|
|
|
IN PPARTENTRY CurrentPart OPTIONAL)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PLIST_ENTRY DiskListEntry;
|
|
|
|
PLIST_ENTRY PartListEntry;
|
2019-03-05 00:42:33 +00:00
|
|
|
PDISKENTRY CurrentDisk;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
/* Fail if no disks are available */
|
|
|
|
if (IsListEmpty(&List->DiskListHead))
|
|
|
|
return NULL;
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Check for the next usable entry on the current partition's disk */
|
|
|
|
if (CurrentPart != NULL)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentDisk = CurrentPart->DiskEntry;
|
|
|
|
|
|
|
|
if (CurrentPart->LogicalPartition)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
/* Logical partition */
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
PartListEntry = CurrentPart->ListEntry.Flink;
|
|
|
|
if (PartListEntry != &CurrentDisk->LogicalPartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
/* Next logical partition */
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentPart = CONTAINING_RECORD(PartListEntry, PARTENTRY, ListEntry);
|
|
|
|
return CurrentPart;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
PartListEntry = CurrentDisk->ExtendedPartition->ListEntry.Flink;
|
|
|
|
if (PartListEntry != &CurrentDisk->PrimaryPartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentPart = CONTAINING_RECORD(PartListEntry, PARTENTRY, ListEntry);
|
|
|
|
return CurrentPart;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Primary or extended partition */
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
if (CurrentPart->IsPartitioned &&
|
|
|
|
IsContainerPartition(CurrentPart->PartitionType))
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
/* First logical partition */
|
2019-03-05 00:42:33 +00:00
|
|
|
PartListEntry = CurrentDisk->LogicalPartListHead.Flink;
|
|
|
|
if (PartListEntry != &CurrentDisk->LogicalPartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentPart = CONTAINING_RECORD(PartListEntry, PARTENTRY, ListEntry);
|
|
|
|
return CurrentPart;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Next primary partition */
|
2019-03-05 00:42:33 +00:00
|
|
|
PartListEntry = CurrentPart->ListEntry.Flink;
|
|
|
|
if (PartListEntry != &CurrentDisk->PrimaryPartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentPart = CONTAINING_RECORD(PartListEntry, PARTENTRY, ListEntry);
|
|
|
|
return CurrentPart;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Search for the first partition entry on the next disk */
|
2019-03-05 00:42:33 +00:00
|
|
|
for (DiskListEntry = (CurrentPart ? CurrentDisk->ListEntry.Flink
|
|
|
|
: List->DiskListHead.Flink);
|
2018-12-08 23:36:56 +00:00
|
|
|
DiskListEntry != &List->DiskListHead;
|
|
|
|
DiskListEntry = DiskListEntry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentDisk = CONTAINING_RECORD(DiskListEntry, DISKENTRY, ListEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
if (CurrentDisk->DiskStyle == PARTITION_STYLE_GPT)
|
2018-12-13 23:30:12 +00:00
|
|
|
{
|
|
|
|
DPRINT("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
PartListEntry = CurrentDisk->PrimaryPartListHead.Flink;
|
|
|
|
if (PartListEntry != &CurrentDisk->PrimaryPartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentPart = CONTAINING_RECORD(PartListEntry, PARTENTRY, ListEntry);
|
|
|
|
return CurrentPart;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
PPARTENTRY
|
|
|
|
GetPrevPartition(
|
2019-03-05 00:42:33 +00:00
|
|
|
IN PPARTLIST List,
|
|
|
|
IN PPARTENTRY CurrentPart OPTIONAL)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PLIST_ENTRY DiskListEntry;
|
|
|
|
PLIST_ENTRY PartListEntry;
|
2019-03-05 00:42:33 +00:00
|
|
|
PDISKENTRY CurrentDisk;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
/* Fail if no disks are available */
|
|
|
|
if (IsListEmpty(&List->DiskListHead))
|
|
|
|
return NULL;
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Check for the previous usable entry on the current partition's disk */
|
|
|
|
if (CurrentPart != NULL)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentDisk = CurrentPart->DiskEntry;
|
|
|
|
|
|
|
|
if (CurrentPart->LogicalPartition)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
/* Logical partition */
|
2019-03-05 00:42:33 +00:00
|
|
|
|
|
|
|
PartListEntry = CurrentPart->ListEntry.Blink;
|
|
|
|
if (PartListEntry != &CurrentDisk->LogicalPartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
/* Previous logical partition */
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentPart = CONTAINING_RECORD(PartListEntry, PARTENTRY, ListEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Extended partition */
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentPart = CurrentDisk->ExtendedPartition;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
2019-03-05 00:42:33 +00:00
|
|
|
return CurrentPart;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Primary or extended partition */
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
PartListEntry = CurrentPart->ListEntry.Blink;
|
|
|
|
if (PartListEntry != &CurrentDisk->PrimaryPartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentPart = CONTAINING_RECORD(PartListEntry, PARTENTRY, ListEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
if (CurrentPart->IsPartitioned &&
|
|
|
|
IsContainerPartition(CurrentPart->PartitionType))
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
PartListEntry = CurrentDisk->LogicalPartListHead.Blink;
|
|
|
|
CurrentPart = CONTAINING_RECORD(PartListEntry, PARTENTRY, ListEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
return CurrentPart;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Search for the last partition entry on the previous disk */
|
2019-03-05 00:42:33 +00:00
|
|
|
for (DiskListEntry = (CurrentPart ? CurrentDisk->ListEntry.Blink
|
|
|
|
: List->DiskListHead.Blink);
|
2018-12-08 23:36:56 +00:00
|
|
|
DiskListEntry != &List->DiskListHead;
|
|
|
|
DiskListEntry = DiskListEntry->Blink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentDisk = CONTAINING_RECORD(DiskListEntry, DISKENTRY, ListEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
if (CurrentDisk->DiskStyle == PARTITION_STYLE_GPT)
|
2018-12-13 23:30:12 +00:00
|
|
|
{
|
|
|
|
DPRINT("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
PartListEntry = CurrentDisk->PrimaryPartListHead.Blink;
|
|
|
|
if (PartListEntry != &CurrentDisk->PrimaryPartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentPart = CONTAINING_RECORD(PartListEntry, PARTENTRY, ListEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
if (CurrentPart->IsPartitioned &&
|
|
|
|
IsContainerPartition(CurrentPart->PartitionType))
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
PartListEntry = CurrentDisk->LogicalPartListHead.Blink;
|
|
|
|
if (PartListEntry != &CurrentDisk->LogicalPartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
CurrentPart = CONTAINING_RECORD(PartListEntry, PARTENTRY, ListEntry);
|
|
|
|
return CurrentPart;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
return CurrentPart;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2023-12-07 22:29:28 +00:00
|
|
|
static inline
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
BOOLEAN
|
|
|
|
IsEmptyLayoutEntry(
|
2023-12-07 22:29:28 +00:00
|
|
|
_In_ PPARTITION_INFORMATION PartitionInfo)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2023-12-07 22:29:28 +00:00
|
|
|
return (PartitionInfo->StartingOffset.QuadPart == 0 &&
|
|
|
|
PartitionInfo->PartitionLength.QuadPart == 0);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
2023-12-07 22:29:28 +00:00
|
|
|
static inline
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
BOOLEAN
|
|
|
|
IsSamePrimaryLayoutEntry(
|
2023-12-07 22:29:28 +00:00
|
|
|
_In_ PPARTITION_INFORMATION PartitionInfo,
|
|
|
|
_In_ PPARTENTRY PartEntry)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2023-12-07 22:29:28 +00:00
|
|
|
return ((PartitionInfo->StartingOffset.QuadPart == GetPartEntryOffsetInBytes(PartEntry)) &&
|
|
|
|
(PartitionInfo->PartitionLength.QuadPart == GetPartEntrySizeInBytes(PartEntry)));
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
// PartitionInfo->PartitionType == PartEntry->PartitionType
|
|
|
|
}
|
|
|
|
|
2024-07-04 13:28:53 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @brief
|
|
|
|
* Counts the number of partitioned disk regions in a given partition list.
|
|
|
|
**/
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
static
|
|
|
|
ULONG
|
2024-07-04 13:28:53 +00:00
|
|
|
GetPartitionCount(
|
|
|
|
_In_ PLIST_ENTRY PartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
ULONG Count = 0;
|
|
|
|
|
2024-07-04 13:28:53 +00:00
|
|
|
for (Entry = PartListHead->Flink;
|
|
|
|
Entry != PartListHead;
|
2018-12-08 23:36:56 +00:00
|
|
|
Entry = Entry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(Entry, PARTENTRY, ListEntry);
|
|
|
|
if (PartEntry->IsPartitioned)
|
2024-07-04 13:28:53 +00:00
|
|
|
++Count;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return Count;
|
|
|
|
}
|
|
|
|
|
2024-07-04 13:28:53 +00:00
|
|
|
#define GetPrimaryPartitionCount(DiskEntry) \
|
|
|
|
GetPartitionCount(&(DiskEntry)->PrimaryPartListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2024-07-04 13:28:53 +00:00
|
|
|
#define GetLogicalPartitionCount(DiskEntry) \
|
|
|
|
(((DiskEntry)->DiskStyle == PARTITION_STYLE_MBR) \
|
|
|
|
? GetPartitionCount(&(DiskEntry)->LogicalPartListHead) : 0)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
static
|
|
|
|
BOOLEAN
|
|
|
|
ReAllocateLayoutBuffer(
|
|
|
|
IN PDISKENTRY DiskEntry)
|
|
|
|
{
|
|
|
|
PDRIVE_LAYOUT_INFORMATION NewLayoutBuffer;
|
|
|
|
ULONG NewPartitionCount;
|
|
|
|
ULONG CurrentPartitionCount = 0;
|
|
|
|
ULONG LayoutBufferSize;
|
|
|
|
ULONG i;
|
|
|
|
|
|
|
|
DPRINT1("ReAllocateLayoutBuffer()\n");
|
|
|
|
|
|
|
|
NewPartitionCount = 4 + GetLogicalPartitionCount(DiskEntry) * 4;
|
|
|
|
|
|
|
|
if (DiskEntry->LayoutBuffer)
|
|
|
|
CurrentPartitionCount = DiskEntry->LayoutBuffer->PartitionCount;
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
DPRINT1("CurrentPartitionCount: %lu ; NewPartitionCount: %lu\n",
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
CurrentPartitionCount, NewPartitionCount);
|
|
|
|
|
|
|
|
if (CurrentPartitionCount == NewPartitionCount)
|
|
|
|
return TRUE;
|
|
|
|
|
|
|
|
LayoutBufferSize = sizeof(DRIVE_LAYOUT_INFORMATION) +
|
|
|
|
((NewPartitionCount - ANYSIZE_ARRAY) * sizeof(PARTITION_INFORMATION));
|
|
|
|
NewLayoutBuffer = RtlReAllocateHeap(ProcessHeap,
|
|
|
|
HEAP_ZERO_MEMORY,
|
|
|
|
DiskEntry->LayoutBuffer,
|
|
|
|
LayoutBufferSize);
|
|
|
|
if (NewLayoutBuffer == NULL)
|
|
|
|
{
|
|
|
|
DPRINT1("Failed to allocate the new layout buffer (size: %lu)\n", LayoutBufferSize);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
NewLayoutBuffer->PartitionCount = NewPartitionCount;
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
/* If the layout buffer grows, make sure the new (empty) entries are written to the disk */
|
|
|
|
if (NewPartitionCount > CurrentPartitionCount)
|
|
|
|
{
|
|
|
|
for (i = CurrentPartitionCount; i < NewPartitionCount; i++)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
NewLayoutBuffer->PartitionEntry[i].RewritePartition = TRUE;
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DiskEntry->LayoutBuffer = NewLayoutBuffer;
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
VOID
|
|
|
|
UpdateDiskLayout(
|
|
|
|
IN PDISKENTRY DiskEntry)
|
|
|
|
{
|
|
|
|
PPARTITION_INFORMATION PartitionInfo;
|
2024-06-06 20:19:04 +00:00
|
|
|
PPARTITION_INFORMATION LinkInfo;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PLIST_ENTRY ListEntry;
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
LARGE_INTEGER HiddenSectors64;
|
|
|
|
ULONG Index;
|
|
|
|
ULONG PartitionNumber = 1;
|
|
|
|
|
|
|
|
DPRINT1("UpdateDiskLayout()\n");
|
|
|
|
|
2018-12-13 23:30:12 +00:00
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
2019-02-24 18:04:57 +00:00
|
|
|
DPRINT1("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
2018-12-13 23:30:12 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
/* Resize the layout buffer if necessary */
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!ReAllocateLayoutBuffer(DiskEntry))
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
DPRINT("ReAllocateLayoutBuffer() failed.\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Update the primary partition table */
|
|
|
|
Index = 0;
|
2018-12-08 23:36:56 +00:00
|
|
|
for (ListEntry = DiskEntry->PrimaryPartListHead.Flink;
|
|
|
|
ListEntry != &DiskEntry->PrimaryPartListHead;
|
|
|
|
ListEntry = ListEntry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(ListEntry, PARTENTRY, ListEntry);
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
if (PartEntry->IsPartitioned)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-02-24 18:04:57 +00:00
|
|
|
ASSERT(PartEntry->PartitionType != PARTITION_ENTRY_UNUSED);
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartitionInfo = &DiskEntry->LayoutBuffer->PartitionEntry[Index];
|
2018-11-22 02:26:47 +00:00
|
|
|
PartEntry->PartitionIndex = Index;
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Reset the current partition number only for not-yet written partitions */
|
2018-11-22 02:26:47 +00:00
|
|
|
if (PartEntry->New)
|
|
|
|
PartEntry->PartitionNumber = 0;
|
|
|
|
|
2019-02-24 18:04:57 +00:00
|
|
|
PartEntry->OnDiskPartitionNumber = (!IsContainerPartition(PartEntry->PartitionType) ? PartitionNumber : 0);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2023-12-07 22:29:28 +00:00
|
|
|
if (!IsSamePrimaryLayoutEntry(PartitionInfo, PartEntry))
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
DPRINT1("Updating primary partition entry %lu\n", Index);
|
|
|
|
|
2023-12-07 22:29:28 +00:00
|
|
|
PartitionInfo->StartingOffset.QuadPart = GetPartEntryOffsetInBytes(PartEntry);
|
|
|
|
PartitionInfo->PartitionLength.QuadPart = GetPartEntrySizeInBytes(PartEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartitionInfo->HiddenSectors = PartEntry->StartSector.LowPart;
|
2018-11-22 02:26:47 +00:00
|
|
|
PartitionInfo->PartitionNumber = PartEntry->PartitionNumber;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartitionInfo->PartitionType = PartEntry->PartitionType;
|
|
|
|
PartitionInfo->BootIndicator = PartEntry->BootIndicator;
|
2018-11-22 02:26:47 +00:00
|
|
|
PartitionInfo->RecognizedPartition = IsRecognizedPartition(PartEntry->PartitionType);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartitionInfo->RewritePartition = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!IsContainerPartition(PartEntry->PartitionType))
|
|
|
|
PartitionNumber++;
|
|
|
|
|
|
|
|
Index++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-18 18:07:23 +00:00
|
|
|
ASSERT(Index <= 4);
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
/* Update the logical partition table */
|
2024-06-06 20:19:04 +00:00
|
|
|
LinkInfo = NULL;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Index = 4;
|
2018-12-08 23:36:56 +00:00
|
|
|
for (ListEntry = DiskEntry->LogicalPartListHead.Flink;
|
|
|
|
ListEntry != &DiskEntry->LogicalPartListHead;
|
|
|
|
ListEntry = ListEntry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(ListEntry, PARTENTRY, ListEntry);
|
|
|
|
|
|
|
|
if (PartEntry->IsPartitioned)
|
|
|
|
{
|
2019-02-24 18:04:57 +00:00
|
|
|
ASSERT(PartEntry->PartitionType != PARTITION_ENTRY_UNUSED);
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartitionInfo = &DiskEntry->LayoutBuffer->PartitionEntry[Index];
|
2018-11-22 02:26:47 +00:00
|
|
|
PartEntry->PartitionIndex = Index;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Reset the current partition number only for not-yet written partitions */
|
2018-11-22 02:26:47 +00:00
|
|
|
if (PartEntry->New)
|
|
|
|
PartEntry->PartitionNumber = 0;
|
|
|
|
|
|
|
|
PartEntry->OnDiskPartitionNumber = PartitionNumber;
|
|
|
|
|
2019-02-24 18:04:57 +00:00
|
|
|
DPRINT1("Updating logical partition entry %lu\n", Index);
|
|
|
|
|
2023-12-07 22:29:28 +00:00
|
|
|
PartitionInfo->StartingOffset.QuadPart = GetPartEntryOffsetInBytes(PartEntry);
|
|
|
|
PartitionInfo->PartitionLength.QuadPart = GetPartEntrySizeInBytes(PartEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartitionInfo->HiddenSectors = DiskEntry->SectorAlignment;
|
2018-11-22 02:26:47 +00:00
|
|
|
PartitionInfo->PartitionNumber = PartEntry->PartitionNumber;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartitionInfo->PartitionType = PartEntry->PartitionType;
|
|
|
|
PartitionInfo->BootIndicator = FALSE;
|
2018-11-22 02:26:47 +00:00
|
|
|
PartitionInfo->RecognizedPartition = IsRecognizedPartition(PartEntry->PartitionType);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartitionInfo->RewritePartition = TRUE;
|
|
|
|
|
|
|
|
/* Fill the link entry of the previous partition entry */
|
2024-06-06 20:19:04 +00:00
|
|
|
if (LinkInfo)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
LinkInfo->StartingOffset.QuadPart = (PartEntry->StartSector.QuadPart - DiskEntry->SectorAlignment) * DiskEntry->BytesPerSector;
|
|
|
|
LinkInfo->PartitionLength.QuadPart = (PartEntry->StartSector.QuadPart + DiskEntry->SectorAlignment) * DiskEntry->BytesPerSector;
|
|
|
|
HiddenSectors64.QuadPart = PartEntry->StartSector.QuadPart - DiskEntry->SectorAlignment - DiskEntry->ExtendedPartition->StartSector.QuadPart;
|
|
|
|
LinkInfo->HiddenSectors = HiddenSectors64.LowPart;
|
|
|
|
LinkInfo->PartitionNumber = 0;
|
2024-06-06 20:19:04 +00:00
|
|
|
|
|
|
|
/* Extended partition links only use type 0x05, as observed
|
|
|
|
* on Windows NT. Alternatively they could inherit the type
|
|
|
|
* of the main extended container. */
|
|
|
|
LinkInfo->PartitionType = PARTITION_EXTENDED; // DiskEntry->ExtendedPartition->PartitionType;
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
LinkInfo->BootIndicator = FALSE;
|
|
|
|
LinkInfo->RecognizedPartition = FALSE;
|
|
|
|
LinkInfo->RewritePartition = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Save a pointer to the link entry of the current partition entry */
|
|
|
|
LinkInfo = &DiskEntry->LayoutBuffer->PartitionEntry[Index + 1];
|
|
|
|
|
|
|
|
PartitionNumber++;
|
|
|
|
Index += 4;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Wipe unused primary partition entries */
|
|
|
|
for (Index = GetPrimaryPartitionCount(DiskEntry); Index < 4; Index++)
|
|
|
|
{
|
|
|
|
DPRINT1("Primary partition entry %lu\n", Index);
|
|
|
|
|
|
|
|
PartitionInfo = &DiskEntry->LayoutBuffer->PartitionEntry[Index];
|
|
|
|
|
|
|
|
if (!IsEmptyLayoutEntry(PartitionInfo))
|
|
|
|
{
|
|
|
|
DPRINT1("Wiping primary partition entry %lu\n", Index);
|
|
|
|
|
|
|
|
PartitionInfo->StartingOffset.QuadPart = 0;
|
|
|
|
PartitionInfo->PartitionLength.QuadPart = 0;
|
|
|
|
PartitionInfo->HiddenSectors = 0;
|
|
|
|
PartitionInfo->PartitionNumber = 0;
|
|
|
|
PartitionInfo->PartitionType = PARTITION_ENTRY_UNUSED;
|
|
|
|
PartitionInfo->BootIndicator = FALSE;
|
|
|
|
PartitionInfo->RecognizedPartition = FALSE;
|
|
|
|
PartitionInfo->RewritePartition = TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Wipe unused logical partition entries */
|
|
|
|
for (Index = 4; Index < DiskEntry->LayoutBuffer->PartitionCount; Index++)
|
|
|
|
{
|
|
|
|
if (Index % 4 >= 2)
|
|
|
|
{
|
|
|
|
DPRINT1("Logical partition entry %lu\n", Index);
|
|
|
|
|
|
|
|
PartitionInfo = &DiskEntry->LayoutBuffer->PartitionEntry[Index];
|
|
|
|
|
|
|
|
if (!IsEmptyLayoutEntry(PartitionInfo))
|
|
|
|
{
|
|
|
|
DPRINT1("Wiping partition entry %lu\n", Index);
|
|
|
|
|
|
|
|
PartitionInfo->StartingOffset.QuadPart = 0;
|
|
|
|
PartitionInfo->PartitionLength.QuadPart = 0;
|
|
|
|
PartitionInfo->HiddenSectors = 0;
|
|
|
|
PartitionInfo->PartitionNumber = 0;
|
|
|
|
PartitionInfo->PartitionType = PARTITION_ENTRY_UNUSED;
|
|
|
|
PartitionInfo->BootIndicator = FALSE;
|
|
|
|
PartitionInfo->RecognizedPartition = FALSE;
|
|
|
|
PartitionInfo->RewritePartition = TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-24 03:34:56 +00:00
|
|
|
// HACK: See the FIXMEs in WritePartitions(): (Re)set the PartitionStyle to MBR.
|
|
|
|
DiskEntry->DiskStyle = PARTITION_STYLE_MBR;
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
DiskEntry->Dirty = TRUE;
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
#ifdef DUMP_PARTITION_TABLE
|
|
|
|
DumpPartitionTable(DiskEntry);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2024-07-04 13:28:53 +00:00
|
|
|
/**
|
|
|
|
* @brief
|
|
|
|
* Retrieves, if any, the unpartitioned disk region that is adjacent
|
|
|
|
* (next or previous) to the specified partition.
|
|
|
|
*
|
|
|
|
* @param[in] PartEntry
|
|
|
|
* Partition from where to find the adjacent unpartitioned region.
|
|
|
|
*
|
|
|
|
* @param[in] Direction
|
|
|
|
* TRUE or FALSE to search the next or previous region, respectively.
|
|
|
|
*
|
|
|
|
* @return The adjacent unpartitioned region, if it exists, or NULL.
|
|
|
|
**/
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PPARTENTRY
|
2024-07-04 13:28:53 +00:00
|
|
|
GetAdjUnpartitionedEntry(
|
|
|
|
_In_ PPARTENTRY PartEntry,
|
|
|
|
_In_ BOOLEAN Direction)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
PDISKENTRY DiskEntry = PartEntry->DiskEntry;
|
2024-07-04 13:28:53 +00:00
|
|
|
PLIST_ENTRY ListHead, AdjEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2024-07-04 13:28:53 +00:00
|
|
|
/* In case of MBR disks only, check the logical partitions if necessary */
|
|
|
|
if ((DiskEntry->DiskStyle == PARTITION_STYLE_MBR) &&
|
|
|
|
PartEntry->LogicalPartition)
|
2018-12-13 23:30:12 +00:00
|
|
|
{
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
ListHead = &DiskEntry->LogicalPartListHead;
|
|
|
|
}
|
2024-07-04 13:28:53 +00:00
|
|
|
else
|
2018-12-13 23:30:12 +00:00
|
|
|
{
|
2024-07-04 13:28:53 +00:00
|
|
|
ListHead = &DiskEntry->PrimaryPartListHead;
|
2018-12-13 23:30:12 +00:00
|
|
|
}
|
|
|
|
|
2024-07-04 13:28:53 +00:00
|
|
|
if (Direction)
|
|
|
|
AdjEntry = PartEntry->ListEntry.Flink; // Next region.
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
else
|
2024-07-04 13:28:53 +00:00
|
|
|
AdjEntry = PartEntry->ListEntry.Blink; // Previous region.
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2024-07-04 13:28:53 +00:00
|
|
|
if (AdjEntry != ListHead)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2024-07-04 13:28:53 +00:00
|
|
|
PartEntry = CONTAINING_RECORD(AdjEntry, PARTENTRY, ListEntry);
|
|
|
|
if (!PartEntry->IsPartitioned)
|
2019-02-24 18:04:57 +00:00
|
|
|
{
|
2024-07-04 13:28:53 +00:00
|
|
|
ASSERT(PartEntry->PartitionType == PARTITION_ENTRY_UNUSED);
|
|
|
|
return PartEntry;
|
2019-02-24 18:04:57 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2023-10-26 19:44:41 +00:00
|
|
|
ERROR_NUMBER
|
|
|
|
PartitionCreationChecks(
|
|
|
|
_In_ PPARTENTRY PartEntry)
|
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry = PartEntry->DiskEntry;
|
|
|
|
|
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
|
|
|
DPRINT1("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
return ERROR_WARN_PARTITION;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fail if the partition is already in use */
|
|
|
|
if (PartEntry->IsPartitioned)
|
|
|
|
return ERROR_NEW_PARTITION;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For primary partitions
|
|
|
|
*/
|
|
|
|
if (!PartEntry->LogicalPartition)
|
|
|
|
{
|
|
|
|
/* Only one primary partition is allowed on super-floppy */
|
|
|
|
if (IsSuperFloppy(DiskEntry))
|
|
|
|
return ERROR_PARTITION_TABLE_FULL;
|
|
|
|
|
|
|
|
/* Fail if there are already 4 primary partitions in the list */
|
|
|
|
if (GetPrimaryPartitionCount(DiskEntry) >= 4)
|
|
|
|
return ERROR_PARTITION_TABLE_FULL;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* For logical partitions
|
|
|
|
*/
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// TODO: Check that we are inside an extended partition!!
|
|
|
|
// Then the following check will be useless.
|
|
|
|
|
|
|
|
/* Only one (primary) partition is allowed on super-floppy */
|
|
|
|
if (IsSuperFloppy(DiskEntry))
|
|
|
|
return ERROR_PARTITION_TABLE_FULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ERROR_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
ERROR_NUMBER
|
|
|
|
ExtendedPartitionCreationChecks(
|
|
|
|
_In_ PPARTENTRY PartEntry)
|
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry = PartEntry->DiskEntry;
|
|
|
|
|
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
|
|
|
DPRINT1("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
return ERROR_WARN_PARTITION;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fail if the partition is already in use */
|
|
|
|
if (PartEntry->IsPartitioned)
|
|
|
|
return ERROR_NEW_PARTITION;
|
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
/* Cannot create an extended partition within logical partition space */
|
|
|
|
if (PartEntry->LogicalPartition)
|
|
|
|
return ERROR_ONLY_ONE_EXTENDED;
|
|
|
|
|
2023-10-26 19:44:41 +00:00
|
|
|
/* Only one primary partition is allowed on super-floppy */
|
|
|
|
if (IsSuperFloppy(DiskEntry))
|
|
|
|
return ERROR_PARTITION_TABLE_FULL;
|
|
|
|
|
|
|
|
/* Fail if there are already 4 primary partitions in the list */
|
|
|
|
if (GetPrimaryPartitionCount(DiskEntry) >= 4)
|
|
|
|
return ERROR_PARTITION_TABLE_FULL;
|
|
|
|
|
|
|
|
/* Fail if there is another extended partition in the list */
|
2024-06-06 20:19:04 +00:00
|
|
|
if (DiskEntry->ExtendedPartition)
|
2023-10-26 19:44:41 +00:00
|
|
|
return ERROR_ONLY_ONE_EXTENDED;
|
|
|
|
|
|
|
|
return ERROR_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
// TODO: Improve upon the PartitionInfo parameter later
|
|
|
|
// (see VDS::CREATE_PARTITION_PARAMETERS and PPARTITION_INFORMATION_MBR/GPT for example)
|
|
|
|
// So far we only use it as the optional type of the partition to create.
|
2018-11-18 18:07:23 +00:00
|
|
|
BOOLEAN
|
2023-10-26 19:44:41 +00:00
|
|
|
CreatePartition(
|
|
|
|
_In_ PPARTLIST List,
|
|
|
|
_Inout_ PPARTENTRY PartEntry,
|
2024-06-06 20:19:04 +00:00
|
|
|
_In_opt_ ULONGLONG SizeBytes,
|
|
|
|
_In_opt_ ULONG_PTR PartitionInfo)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2018-11-18 18:07:23 +00:00
|
|
|
ERROR_NUMBER Error;
|
2024-06-06 20:19:04 +00:00
|
|
|
BOOLEAN isContainer = IsContainerPartition((UCHAR)PartitionInfo);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PDISKENTRY DiskEntry;
|
2024-06-06 20:19:04 +00:00
|
|
|
PCSTR mainType = "Primary";
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
if (isContainer)
|
|
|
|
mainType = "Extended";
|
|
|
|
else if (PartEntry && PartEntry->LogicalPartition)
|
|
|
|
mainType = "Logical";
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
DPRINT1("CreatePartition(%s, %I64u bytes)\n", mainType, SizeBytes);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
if (!List || !PartEntry ||
|
|
|
|
!PartEntry->DiskEntry || PartEntry->IsPartitioned)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2018-11-18 18:07:23 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
if (isContainer)
|
|
|
|
Error = ExtendedPartitionCreationChecks(PartEntry);
|
|
|
|
else
|
|
|
|
Error = PartitionCreationChecks(PartEntry);
|
2018-11-18 18:07:23 +00:00
|
|
|
if (Error != NOT_AN_ERROR)
|
|
|
|
{
|
2024-06-06 20:19:04 +00:00
|
|
|
DPRINT1("PartitionCreationChecks(%s) failed with error %lu\n", mainType, Error);
|
2018-11-18 18:07:23 +00:00
|
|
|
return FALSE;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
2019-08-24 23:32:46 +00:00
|
|
|
/* Initialize the partition entry, inserting a new blank region if needed */
|
2024-06-06 20:19:04 +00:00
|
|
|
if (!InitializePartitionEntry(PartEntry, SizeBytes, PartitionInfo))
|
2018-11-22 02:26:47 +00:00
|
|
|
return FALSE;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
DiskEntry = PartEntry->DiskEntry;
|
|
|
|
UpdateDiskLayout(DiskEntry);
|
|
|
|
|
|
|
|
ASSERT(!PartEntry->Volume);
|
|
|
|
if (!isContainer)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* We create a primary/logical partition: initialize a new basic
|
|
|
|
* volume entry. When the partition will actually be written onto
|
|
|
|
* the disk, the PARTMGR will notify the MOUNTMGR that a volume
|
|
|
|
* associated with this partition has to be created. */
|
|
|
|
PartEntry->Volume = InitVolume(DiskEntry->PartList, PartEntry);
|
|
|
|
ASSERT(PartEntry->Volume);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
AssignDriveLetters(List);
|
2018-11-18 18:07:23 +00:00
|
|
|
|
|
|
|
return TRUE;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
static NTSTATUS
|
|
|
|
DismountPartition(
|
|
|
|
_In_ PPARTLIST List,
|
|
|
|
_In_ PPARTENTRY PartEntry)
|
2018-11-16 02:02:28 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PVOLENTRY Volume = PartEntry->Volume;
|
|
|
|
|
|
|
|
ASSERT(PartEntry->DiskEntry->PartList == List);
|
2018-11-16 02:02:28 +00:00
|
|
|
|
2019-02-24 18:04:57 +00:00
|
|
|
/* Check whether the partition is valid and was mounted by the system */
|
2018-11-16 02:02:28 +00:00
|
|
|
if (!PartEntry->IsPartitioned ||
|
2019-02-24 18:04:57 +00:00
|
|
|
IsContainerPartition(PartEntry->PartitionType) ||
|
|
|
|
!IsRecognizedPartition(PartEntry->PartitionType) ||
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
!Volume || Volume->FormatState == UnknownFormat ||
|
2019-08-24 23:32:46 +00:00
|
|
|
// NOTE: If FormatState == Unformatted but *FileSystem != 0 this means
|
|
|
|
// it has been usually mounted with RawFS and thus needs to be dismounted.
|
2018-11-16 02:02:28 +00:00
|
|
|
PartEntry->PartitionNumber == 0)
|
|
|
|
{
|
|
|
|
/* The partition is not mounted, so just return success */
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2019-02-24 18:04:57 +00:00
|
|
|
ASSERT(PartEntry->PartitionType != PARTITION_ENTRY_UNUSED);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
ASSERT(Volume->PartEntry == PartEntry);
|
|
|
|
|
|
|
|
/* Unlink the basic volume from the volumes list and dismount it */
|
|
|
|
PartEntry->Volume = NULL;
|
|
|
|
Volume->PartEntry = NULL;
|
|
|
|
RemoveEntryList(&Volume->ListEntry);
|
|
|
|
Status = DismountVolume(&Volume->Info, TRUE);
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, Volume);
|
2018-11-16 02:02:28 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
BOOLEAN
|
2019-02-24 18:04:57 +00:00
|
|
|
DeletePartition(
|
2024-06-06 20:19:04 +00:00
|
|
|
_In_ PPARTLIST List,
|
|
|
|
_In_ PPARTENTRY PartEntry,
|
|
|
|
_Out_opt_ PPARTENTRY* FreeRegion)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
PPARTENTRY PrevPartEntry;
|
|
|
|
PPARTENTRY NextPartEntry;
|
|
|
|
PPARTENTRY LogicalPartEntry;
|
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
|
2024-06-06 20:19:04 +00:00
|
|
|
if (!List || !PartEntry ||
|
|
|
|
!PartEntry->DiskEntry || !PartEntry->IsPartitioned)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
return FALSE;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
ASSERT(PartEntry->DiskEntry->PartList == List);
|
2019-02-24 18:04:57 +00:00
|
|
|
ASSERT(PartEntry->PartitionType != PARTITION_ENTRY_UNUSED);
|
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Clear the system partition if it is being deleted */
|
2019-02-24 18:04:57 +00:00
|
|
|
if (List->SystemPartition == PartEntry)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-02-24 18:04:57 +00:00
|
|
|
ASSERT(List->SystemPartition);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
List->SystemPartition = NULL;
|
|
|
|
}
|
|
|
|
|
2019-02-24 18:04:57 +00:00
|
|
|
DiskEntry = PartEntry->DiskEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2018-11-16 02:02:28 +00:00
|
|
|
/* Check which type of partition (primary/logical or extended) is being deleted */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
if (DiskEntry->ExtendedPartition == PartEntry)
|
|
|
|
{
|
2018-11-16 02:02:28 +00:00
|
|
|
/* An extended partition is being deleted: delete all logical partition entries */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
while (!IsListEmpty(&DiskEntry->LogicalPartListHead))
|
|
|
|
{
|
|
|
|
Entry = RemoveHeadList(&DiskEntry->LogicalPartListHead);
|
|
|
|
LogicalPartEntry = CONTAINING_RECORD(Entry, PARTENTRY, ListEntry);
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Dismount the logical partition and delete it */
|
|
|
|
DismountPartition(List, LogicalPartEntry);
|
|
|
|
DestroyRegion(LogicalPartEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DiskEntry->ExtendedPartition = NULL;
|
|
|
|
}
|
2018-11-16 02:02:28 +00:00
|
|
|
else
|
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* A primary/logical partition is being deleted: dismount it */
|
|
|
|
DismountPartition(List, PartEntry);
|
2018-11-16 02:02:28 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Adjust the unpartitioned disk space entries */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
/* Get pointer to previous and next unpartitioned entries */
|
2024-07-04 13:28:53 +00:00
|
|
|
PrevPartEntry = GetAdjUnpartitionedEntry(PartEntry, FALSE);
|
|
|
|
NextPartEntry = GetAdjUnpartitionedEntry(PartEntry, TRUE);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
if (PrevPartEntry != NULL && NextPartEntry != NULL)
|
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Merge the previous, current and next unpartitioned entries */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Adjust the previous entry length */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PrevPartEntry->SectorCount.QuadPart += (PartEntry->SectorCount.QuadPart + NextPartEntry->SectorCount.QuadPart);
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Remove the current and next entries */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
RemoveEntryList(&PartEntry->ListEntry);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
DestroyRegion(PartEntry);
|
2017-05-31 01:43:12 +00:00
|
|
|
RemoveEntryList(&NextPartEntry->ListEntry);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
DestroyRegion(NextPartEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Optionally return the freed region */
|
|
|
|
if (FreeRegion)
|
|
|
|
*FreeRegion = PrevPartEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
else if (PrevPartEntry != NULL && NextPartEntry == NULL)
|
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Merge the current and the previous unpartitioned entries */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Adjust the previous entry length */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PrevPartEntry->SectorCount.QuadPart += PartEntry->SectorCount.QuadPart;
|
|
|
|
|
|
|
|
/* Remove the current entry */
|
|
|
|
RemoveEntryList(&PartEntry->ListEntry);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
DestroyRegion(PartEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Optionally return the freed region */
|
|
|
|
if (FreeRegion)
|
|
|
|
*FreeRegion = PrevPartEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
else if (PrevPartEntry == NULL && NextPartEntry != NULL)
|
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Merge the current and the next unpartitioned entries */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Adjust the next entry offset and length */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
NextPartEntry->StartSector.QuadPart = PartEntry->StartSector.QuadPart;
|
|
|
|
NextPartEntry->SectorCount.QuadPart += PartEntry->SectorCount.QuadPart;
|
|
|
|
|
|
|
|
/* Remove the current entry */
|
|
|
|
RemoveEntryList(&PartEntry->ListEntry);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
DestroyRegion(PartEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Optionally return the freed region */
|
|
|
|
if (FreeRegion)
|
|
|
|
*FreeRegion = NextPartEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2019-03-05 00:42:33 +00:00
|
|
|
/* Nothing to merge but change the current entry */
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PartEntry->New = FALSE;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartEntry->IsPartitioned = FALSE;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PartEntry->PartitionType = PARTITION_ENTRY_UNUSED;
|
2019-08-24 23:32:46 +00:00
|
|
|
PartEntry->OnDiskPartitionNumber = 0;
|
|
|
|
PartEntry->PartitionNumber = 0;
|
|
|
|
// PartEntry->PartitionIndex = 0;
|
|
|
|
PartEntry->BootIndicator = FALSE;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PartEntry->DeviceName[0] = UNICODE_NULL;
|
|
|
|
|
|
|
|
if (PartEntry->Volume)
|
|
|
|
{
|
|
|
|
RemoveEntryList(&PartEntry->Volume->ListEntry);
|
|
|
|
RtlFreeHeap(ProcessHeap, 0, PartEntry->Volume);
|
|
|
|
}
|
|
|
|
PartEntry->Volume = NULL;
|
2019-03-05 00:42:33 +00:00
|
|
|
|
|
|
|
/* Optionally return the freed region */
|
|
|
|
if (FreeRegion)
|
|
|
|
*FreeRegion = PartEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
UpdateDiskLayout(DiskEntry);
|
|
|
|
AssignDriveLetters(List);
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
return TRUE;
|
2019-02-24 18:04:57 +00:00
|
|
|
}
|
|
|
|
|
2019-02-24 16:52:33 +00:00
|
|
|
static
|
|
|
|
BOOLEAN
|
|
|
|
IsSupportedActivePartition(
|
|
|
|
IN PPARTENTRY PartEntry)
|
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PVOLENTRY Volume;
|
|
|
|
|
2019-08-24 23:32:46 +00:00
|
|
|
/* Check the type and the file system of this partition */
|
2019-02-24 16:52:33 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We do not support extended partition containers (on MBR disks) marked
|
|
|
|
* as active, and containing code inside their extended boot records.
|
|
|
|
*/
|
|
|
|
if (IsContainerPartition(PartEntry->PartitionType))
|
|
|
|
{
|
|
|
|
DPRINT1("System partition %lu in disk %lu is an extended partition container?!\n",
|
|
|
|
PartEntry->PartitionNumber, PartEntry->DiskEntry->DiskNumber);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
Volume = PartEntry->Volume;
|
|
|
|
if (!Volume)
|
|
|
|
{
|
|
|
|
/* Still no recognizable volume mounted: partition not supported */
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2019-02-24 16:52:33 +00:00
|
|
|
/*
|
|
|
|
* ADDITIONAL CHECKS / BIG HACK:
|
|
|
|
*
|
|
|
|
* Retrieve its file system and check whether we have
|
|
|
|
* write support for it. If that is the case we are fine
|
|
|
|
* and we can use it directly. However if we don't have
|
|
|
|
* write support we will need to change the active system
|
|
|
|
* partition.
|
|
|
|
*
|
|
|
|
* NOTE that this is completely useless on architectures
|
|
|
|
* where a real system partition is required, as on these
|
|
|
|
* architectures the partition uses the FAT FS, for which
|
|
|
|
* we do have write support.
|
|
|
|
* NOTE also that for those architectures looking for a
|
|
|
|
* partition boot indicator is insufficient.
|
|
|
|
*/
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (Volume->FormatState == Unformatted)
|
2019-08-24 23:32:46 +00:00
|
|
|
{
|
|
|
|
/* If this partition is mounted, it would use RawFS ("RAW") */
|
|
|
|
return TRUE;
|
|
|
|
}
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
else if (Volume->FormatState == Formatted)
|
2019-02-24 16:52:33 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
ASSERT(*Volume->Info.FileSystem);
|
2019-02-24 16:52:33 +00:00
|
|
|
|
|
|
|
/* NOTE: Please keep in sync with the RegisteredFileSystems list! */
|
2024-05-11 16:23:44 +00:00
|
|
|
if (_wcsicmp(Volume->Info.FileSystem, L"FAT") == 0 ||
|
|
|
|
_wcsicmp(Volume->Info.FileSystem, L"FAT32") == 0 ||
|
|
|
|
// _wcsicmp(Volume->Info.FileSystem, L"NTFS") == 0 ||
|
|
|
|
_wcsicmp(Volume->Info.FileSystem, L"BTRFS") == 0)
|
2019-02-24 16:52:33 +00:00
|
|
|
{
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// WARNING: We cannot write on this FS yet!
|
|
|
|
DPRINT1("Recognized file system '%S' that doesn't have write support yet!\n",
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
Volume->Info.FileSystem);
|
2019-02-24 16:52:33 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
else // if (Volume->FormatState == UnknownFormat)
|
2019-02-24 16:52:33 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
ASSERT(!*Volume->Info.FileSystem);
|
2019-02-24 16:52:33 +00:00
|
|
|
|
|
|
|
DPRINT1("System partition %lu in disk %lu with no or unknown FS?!\n",
|
|
|
|
PartEntry->PartitionNumber, PartEntry->DiskEntry->DiskNumber);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
// HACK: WARNING: We cannot write on this FS yet!
|
|
|
|
// See fsutil.c:InferFileSystem()
|
|
|
|
if (PartEntry->PartitionType == PARTITION_IFS)
|
|
|
|
{
|
|
|
|
DPRINT1("Recognized file system '%S' that doesn't have write support yet!\n",
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
Volume->Info.FileSystem);
|
2019-02-24 16:52:33 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
PPARTENTRY
|
|
|
|
FindSupportedSystemPartition(
|
2019-03-05 00:42:33 +00:00
|
|
|
IN PPARTLIST List,
|
|
|
|
IN BOOLEAN ForceSelect,
|
2019-08-25 00:08:23 +00:00
|
|
|
IN PDISKENTRY AlternativeDisk OPTIONAL,
|
|
|
|
IN PPARTENTRY AlternativePart OPTIONAL)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-02-25 22:43:20 +00:00
|
|
|
PLIST_ENTRY ListEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PDISKENTRY DiskEntry;
|
|
|
|
PPARTENTRY PartEntry;
|
2019-02-25 22:43:20 +00:00
|
|
|
PPARTENTRY ActivePartition;
|
|
|
|
PPARTENTRY CandidatePartition = NULL;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
/* Check for empty disk list */
|
|
|
|
if (IsListEmpty(&List->DiskListHead))
|
|
|
|
{
|
2019-02-25 22:43:20 +00:00
|
|
|
/* No system partition! */
|
2019-08-25 00:08:23 +00:00
|
|
|
ASSERT(List->SystemPartition == NULL);
|
2019-03-05 00:42:33 +00:00
|
|
|
goto NoSystemPartition;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Adjust the optional alternative disk if needed */
|
|
|
|
if (!AlternativeDisk && AlternativePart)
|
|
|
|
AlternativeDisk = AlternativePart->DiskEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Ensure that the alternative partition is on the alternative disk */
|
|
|
|
if (AlternativePart)
|
|
|
|
ASSERT(AlternativeDisk && (AlternativePart->DiskEntry == AlternativeDisk));
|
2019-03-05 00:42:33 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Ensure that the alternative disk is in the list */
|
|
|
|
if (AlternativeDisk)
|
|
|
|
ASSERT(AlternativeDisk->PartList == List);
|
2019-03-05 00:42:33 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Start fresh */
|
|
|
|
CandidatePartition = NULL;
|
2019-02-25 22:43:20 +00:00
|
|
|
|
|
|
|
//
|
2019-08-25 00:08:23 +00:00
|
|
|
// Step 1 : Check the system disk.
|
2019-02-25 22:43:20 +00:00
|
|
|
//
|
|
|
|
|
|
|
|
/*
|
2019-08-25 00:08:23 +00:00
|
|
|
* First, check whether the system disk, i.e. the one that will be booted
|
|
|
|
* by default by the hardware, contains an active partition. If so this
|
|
|
|
* should be our system partition.
|
2019-02-25 22:43:20 +00:00
|
|
|
*/
|
2019-08-25 00:08:23 +00:00
|
|
|
DiskEntry = GetSystemDisk(List);
|
2024-02-21 17:32:19 +00:00
|
|
|
if (!DiskEntry)
|
|
|
|
{
|
|
|
|
/* No system disk found, directly go check the alternative disk */
|
|
|
|
goto UseAlternativeDisk;
|
|
|
|
}
|
2019-02-25 22:43:20 +00:00
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
2019-08-25 00:08:23 +00:00
|
|
|
DPRINT1("System disk -- GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
goto UseAlternativeDisk;
|
2019-03-05 00:42:33 +00:00
|
|
|
}
|
2019-02-25 22:43:20 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* If we have a system partition (in the system disk), validate it */
|
|
|
|
ActivePartition = List->SystemPartition;
|
|
|
|
if (ActivePartition && IsSupportedActivePartition(ActivePartition))
|
2019-02-25 22:43:20 +00:00
|
|
|
{
|
2019-08-25 00:08:23 +00:00
|
|
|
CandidatePartition = ActivePartition;
|
2019-02-25 22:43:20 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
DPRINT1("Use the current system partition %lu in disk %lu, drive letter %C\n",
|
|
|
|
CandidatePartition->PartitionNumber,
|
|
|
|
CandidatePartition->DiskEntry->DiskNumber,
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
!CandidatePartition->Volume->Info.DriveLetter ? L'-' : CandidatePartition->Volume->Info.DriveLetter);
|
2019-08-25 00:08:23 +00:00
|
|
|
|
|
|
|
/* Return the candidate system partition */
|
|
|
|
return CandidatePartition;
|
2019-02-25 22:43:20 +00:00
|
|
|
}
|
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* If the system disk is not the optional alternative disk, perform the minimal checks */
|
|
|
|
if (DiskEntry != AlternativeDisk)
|
2019-02-25 22:43:20 +00:00
|
|
|
{
|
|
|
|
/*
|
2019-03-05 00:42:33 +00:00
|
|
|
* No active partition has been recognized. Enumerate all the (primary)
|
2019-08-25 00:08:23 +00:00
|
|
|
* partitions in the system disk, excluding the possible current active
|
2019-03-05 00:42:33 +00:00
|
|
|
* partition, to find a new candidate.
|
2019-02-25 22:43:20 +00:00
|
|
|
*/
|
|
|
|
for (ListEntry = DiskEntry->PrimaryPartListHead.Flink;
|
|
|
|
ListEntry != &DiskEntry->PrimaryPartListHead;
|
|
|
|
ListEntry = ListEntry->Flink)
|
|
|
|
{
|
|
|
|
/* Retrieve the partition */
|
|
|
|
PartEntry = CONTAINING_RECORD(ListEntry, PARTENTRY, ListEntry);
|
|
|
|
|
|
|
|
/* Skip the current active partition */
|
2019-08-25 00:08:23 +00:00
|
|
|
if (PartEntry == ActivePartition)
|
2019-02-25 22:43:20 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Check if the partition is partitioned and used */
|
|
|
|
if (PartEntry->IsPartitioned &&
|
|
|
|
!IsContainerPartition(PartEntry->PartitionType))
|
|
|
|
{
|
|
|
|
ASSERT(PartEntry->PartitionType != PARTITION_ENTRY_UNUSED);
|
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* If we get a candidate active partition in the disk, validate it */
|
2019-02-25 22:43:20 +00:00
|
|
|
if (IsSupportedActivePartition(PartEntry))
|
|
|
|
{
|
|
|
|
CandidatePartition = PartEntry;
|
2019-08-25 00:08:23 +00:00
|
|
|
goto UseAlternativePartition;
|
2019-02-25 22:43:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#if 0
|
|
|
|
/* Check if the partition is partitioned and used */
|
|
|
|
if (!PartEntry->IsPartitioned)
|
|
|
|
{
|
|
|
|
ASSERT(PartEntry->PartitionType == PARTITION_ENTRY_UNUSED);
|
|
|
|
|
|
|
|
// TODO: Check for minimal size!!
|
|
|
|
CandidatePartition = PartEntry;
|
2019-08-25 00:08:23 +00:00
|
|
|
goto UseAlternativePartition;
|
2019-02-25 22:43:20 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Still nothing, look whether there is some free space that we can use
|
|
|
|
* for the new system partition. We must be sure that the total number
|
|
|
|
* of partition is less than the maximum allowed, and that the minimal
|
|
|
|
* size is fine.
|
|
|
|
*/
|
|
|
|
//
|
|
|
|
// TODO: Fix the handling of system partition being created in unpartitioned space!!
|
|
|
|
// --> When to partition it? etc...
|
|
|
|
//
|
|
|
|
if (GetPrimaryPartitionCount(DiskEntry) < 4)
|
|
|
|
{
|
|
|
|
for (ListEntry = DiskEntry->PrimaryPartListHead.Flink;
|
|
|
|
ListEntry != &DiskEntry->PrimaryPartListHead;
|
|
|
|
ListEntry = ListEntry->Flink)
|
|
|
|
{
|
|
|
|
/* Retrieve the partition */
|
|
|
|
PartEntry = CONTAINING_RECORD(ListEntry, PARTENTRY, ListEntry);
|
|
|
|
|
|
|
|
/* Skip the current active partition */
|
2019-08-25 00:08:23 +00:00
|
|
|
if (PartEntry == ActivePartition)
|
2019-02-25 22:43:20 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Check for unpartitioned space */
|
|
|
|
if (!PartEntry->IsPartitioned)
|
|
|
|
{
|
|
|
|
ASSERT(PartEntry->PartitionType == PARTITION_ENTRY_UNUSED);
|
|
|
|
|
|
|
|
// TODO: Check for minimal size!!
|
|
|
|
CandidatePartition = PartEntry;
|
2019-08-25 00:08:23 +00:00
|
|
|
goto UseAlternativePartition;
|
2019-02-25 22:43:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
//
|
2019-08-25 00:08:23 +00:00
|
|
|
// Step 2 : No active partition found: Check the alternative disk if specified.
|
2019-02-25 22:43:20 +00:00
|
|
|
//
|
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
UseAlternativeDisk:
|
|
|
|
if (!AlternativeDisk || (!ForceSelect && (DiskEntry != AlternativeDisk)))
|
2019-03-05 00:42:33 +00:00
|
|
|
goto NoSystemPartition;
|
2019-02-25 22:43:20 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
if (AlternativeDisk->DiskStyle == PARTITION_STYLE_GPT)
|
2019-03-05 00:42:33 +00:00
|
|
|
{
|
2019-08-25 00:08:23 +00:00
|
|
|
DPRINT1("Alternative disk -- GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
2019-03-05 00:42:33 +00:00
|
|
|
goto NoSystemPartition;
|
|
|
|
}
|
2019-02-25 22:43:20 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
if (DiskEntry != AlternativeDisk)
|
2019-03-05 00:42:33 +00:00
|
|
|
{
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Choose the alternative disk */
|
|
|
|
DiskEntry = AlternativeDisk;
|
2019-02-25 22:43:20 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* If we get a candidate active partition, validate it */
|
2019-02-25 22:43:20 +00:00
|
|
|
ActivePartition = GetActiveDiskPartition(DiskEntry);
|
2019-08-25 00:08:23 +00:00
|
|
|
if (ActivePartition && IsSupportedActivePartition(ActivePartition))
|
2019-02-25 22:43:20 +00:00
|
|
|
{
|
2019-08-25 00:08:23 +00:00
|
|
|
CandidatePartition = ActivePartition;
|
|
|
|
goto UseAlternativePartition;
|
2019-02-25 22:43:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-03-05 00:42:33 +00:00
|
|
|
/* We now may have an unsupported active partition, or none */
|
2019-02-25 22:43:20 +00:00
|
|
|
|
|
|
|
/***
|
|
|
|
*** TODO: Improve the selection:
|
|
|
|
*** - If we want a really separate system partition from the partition where
|
|
|
|
*** we install, do something similar to what's done below in the code.
|
|
|
|
*** - Otherwise if we allow for the system partition to be also the partition
|
2019-08-25 00:08:23 +00:00
|
|
|
*** where we install, just directly fall down to using AlternativePart.
|
2019-02-25 22:43:20 +00:00
|
|
|
***/
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
/* Retrieve the first partition of the disk */
|
|
|
|
PartEntry = CONTAINING_RECORD(DiskEntry->PrimaryPartListHead.Flink,
|
2019-02-25 22:43:20 +00:00
|
|
|
PARTENTRY, ListEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
ASSERT(DiskEntry == PartEntry->DiskEntry);
|
2019-02-25 22:43:20 +00:00
|
|
|
|
|
|
|
CandidatePartition = PartEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
//
|
|
|
|
// See: https://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/partlist.c?r1=63355&r2=63354&pathrev=63355#l2318
|
|
|
|
//
|
|
|
|
|
|
|
|
/* Check if the disk is new and if so, use its first partition as the active system partition */
|
|
|
|
if (DiskEntry->NewDisk)
|
|
|
|
{
|
2019-02-25 22:43:20 +00:00
|
|
|
// !IsContainerPartition(PartEntry->PartitionType);
|
|
|
|
if (!CandidatePartition->IsPartitioned || !CandidatePartition->BootIndicator) /* CandidatePartition != ActivePartition */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2019-02-25 22:43:20 +00:00
|
|
|
ASSERT(DiskEntry == CandidatePartition->DiskEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
DPRINT1("Use new first active system partition %lu in disk %lu, drive letter %C\n",
|
2019-08-25 00:08:23 +00:00
|
|
|
CandidatePartition->PartitionNumber,
|
|
|
|
CandidatePartition->DiskEntry->DiskNumber,
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
!CandidatePartition->Volume->Info.DriveLetter ? L'-' : CandidatePartition->Volume->Info.DriveLetter);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Return the candidate system partition */
|
|
|
|
return CandidatePartition;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// FIXME: What to do??
|
|
|
|
DPRINT1("NewDisk TRUE but first partition is used?\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The disk is not new, check if any partition is initialized;
|
|
|
|
* if not, the first one becomes the system partition.
|
|
|
|
*/
|
2018-12-08 23:36:56 +00:00
|
|
|
for (ListEntry = DiskEntry->PrimaryPartListHead.Flink;
|
|
|
|
ListEntry != &DiskEntry->PrimaryPartListHead;
|
|
|
|
ListEntry = ListEntry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
2018-12-08 23:36:56 +00:00
|
|
|
/* Retrieve the partition */
|
2019-02-25 22:43:20 +00:00
|
|
|
PartEntry = CONTAINING_RECORD(ListEntry, PARTENTRY, ListEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
/* Check if the partition is partitioned and is used */
|
2019-02-25 22:43:20 +00:00
|
|
|
// !IsContainerPartition(PartEntry->PartitionType);
|
|
|
|
if (/* PartEntry->IsPartitioned && */
|
|
|
|
PartEntry->PartitionType != PARTITION_ENTRY_UNUSED || PartEntry->BootIndicator)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (ListEntry == &DiskEntry->PrimaryPartListHead)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* OK we haven't encountered any used and active partition,
|
|
|
|
* so use the first one as the system partition.
|
|
|
|
*/
|
2019-02-25 22:43:20 +00:00
|
|
|
ASSERT(DiskEntry == CandidatePartition->DiskEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
DPRINT1("Use first active system partition %lu in disk %lu, drive letter %C\n",
|
2019-08-25 00:08:23 +00:00
|
|
|
CandidatePartition->PartitionNumber,
|
|
|
|
CandidatePartition->DiskEntry->DiskNumber,
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
!CandidatePartition->Volume->Info.DriveLetter ? L'-' : CandidatePartition->Volume->Info.DriveLetter);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Return the candidate system partition */
|
|
|
|
return CandidatePartition;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
2019-02-25 22:43:20 +00:00
|
|
|
/*
|
|
|
|
* The disk is not new, we did not find any actual active partition,
|
2019-08-25 00:08:23 +00:00
|
|
|
* or the one we found was not supported, or any possible other candidate
|
|
|
|
* is not supported. We then use the alternative partition if specified.
|
2019-02-25 22:43:20 +00:00
|
|
|
*/
|
2019-08-25 00:08:23 +00:00
|
|
|
if (AlternativePart)
|
2019-03-05 00:42:33 +00:00
|
|
|
{
|
2019-08-25 00:08:23 +00:00
|
|
|
DPRINT1("No valid or supported system partition has been found, use the alternative partition!\n");
|
|
|
|
CandidatePartition = AlternativePart;
|
|
|
|
goto UseAlternativePartition;
|
2019-03-05 00:42:33 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
NoSystemPartition:
|
|
|
|
DPRINT1("No valid or supported system partition has been found on this system!\n");
|
2019-08-25 00:08:23 +00:00
|
|
|
return NULL;
|
2019-03-05 00:42:33 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
UseAlternativePartition:
|
|
|
|
/*
|
|
|
|
* We are here because we did not find any (active) candidate system
|
|
|
|
* partition that we know how to support. What we are going to do is
|
|
|
|
* to change the existing system partition and use the alternative partition
|
|
|
|
* (e.g. on which we install ReactOS) as the new system partition.
|
|
|
|
* Then we will need to add in FreeLdr's boot menu an entry for booting
|
|
|
|
* from the original system partition.
|
|
|
|
*/
|
2019-03-05 00:42:33 +00:00
|
|
|
ASSERT(CandidatePartition);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
DPRINT1("Use alternative active system partition %lu in disk %lu, drive letter %C\n",
|
|
|
|
CandidatePartition->PartitionNumber,
|
|
|
|
CandidatePartition->DiskEntry->DiskNumber,
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
!CandidatePartition->Volume->Info.DriveLetter ? L'-' : CandidatePartition->Volume->Info.DriveLetter);
|
2019-08-25 00:08:23 +00:00
|
|
|
|
|
|
|
/* Return the candidate system partition */
|
|
|
|
return CandidatePartition;
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
SetActivePartition(
|
|
|
|
IN PPARTLIST List,
|
|
|
|
IN PPARTENTRY PartEntry,
|
|
|
|
IN PPARTENTRY OldActivePart OPTIONAL)
|
|
|
|
{
|
|
|
|
/* Check for empty disk list */
|
|
|
|
if (IsListEmpty(&List->DiskListHead))
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
/* Validate the partition entry */
|
|
|
|
if (!PartEntry)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the partition entry is already the system partition, or if it is
|
|
|
|
* the same as the old active partition hint the user provided (and if
|
|
|
|
* it is already active), just return success.
|
|
|
|
*/
|
|
|
|
if ((PartEntry == List->SystemPartition) ||
|
|
|
|
((PartEntry == OldActivePart) && IsPartitionActive(OldActivePart)))
|
|
|
|
{
|
|
|
|
return TRUE;
|
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
ASSERT(PartEntry->DiskEntry);
|
|
|
|
|
|
|
|
/* Ensure that the partition's disk is in the list */
|
|
|
|
ASSERT(PartEntry->DiskEntry->PartList == List);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
/*
|
2019-08-25 00:08:23 +00:00
|
|
|
* If the user provided an old active partition hint, verify that it is
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
* indeed active and belongs to the same disk where the new partition
|
2019-08-25 00:08:23 +00:00
|
|
|
* belongs. Otherwise determine the current active partition on the disk
|
|
|
|
* where the new partition belongs.
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
*/
|
2019-08-25 00:08:23 +00:00
|
|
|
if (!(OldActivePart && IsPartitionActive(OldActivePart) && (OldActivePart->DiskEntry == PartEntry->DiskEntry)))
|
|
|
|
{
|
|
|
|
/* It's not, determine the current active partition for the disk */
|
|
|
|
OldActivePart = GetActiveDiskPartition(PartEntry->DiskEntry);
|
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Unset the old active partition if it exists */
|
|
|
|
if (OldActivePart)
|
2019-02-25 22:43:20 +00:00
|
|
|
{
|
2019-08-25 00:08:23 +00:00
|
|
|
OldActivePart->BootIndicator = FALSE;
|
|
|
|
OldActivePart->DiskEntry->LayoutBuffer->PartitionEntry[OldActivePart->PartitionIndex].BootIndicator = FALSE;
|
|
|
|
OldActivePart->DiskEntry->LayoutBuffer->PartitionEntry[OldActivePart->PartitionIndex].RewritePartition = TRUE;
|
|
|
|
OldActivePart->DiskEntry->Dirty = TRUE;
|
2019-02-25 22:43:20 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Modify the system partition if the new partition is on the system disk */
|
|
|
|
if (PartEntry->DiskEntry == GetSystemDisk(List))
|
|
|
|
List->SystemPartition = PartEntry;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
2019-08-25 00:08:23 +00:00
|
|
|
/* Set the new active partition */
|
|
|
|
PartEntry->BootIndicator = TRUE;
|
|
|
|
PartEntry->DiskEntry->LayoutBuffer->PartitionEntry[PartEntry->PartitionIndex].BootIndicator = TRUE;
|
|
|
|
PartEntry->DiskEntry->LayoutBuffer->PartitionEntry[PartEntry->PartitionIndex].RewritePartition = TRUE;
|
|
|
|
PartEntry->DiskEntry->Dirty = TRUE;
|
|
|
|
|
|
|
|
return TRUE;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
WritePartitions(
|
|
|
|
IN PDISKENTRY DiskEntry)
|
|
|
|
{
|
2018-11-22 02:26:47 +00:00
|
|
|
NTSTATUS Status;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
|
|
|
UNICODE_STRING Name;
|
2018-11-22 02:26:47 +00:00
|
|
|
HANDLE FileHandle;
|
|
|
|
IO_STATUS_BLOCK Iosb;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
ULONG BufferSize;
|
2018-11-22 02:26:47 +00:00
|
|
|
PPARTITION_INFORMATION PartitionInfo;
|
|
|
|
ULONG PartitionCount;
|
|
|
|
PLIST_ENTRY ListEntry;
|
|
|
|
PPARTENTRY PartEntry;
|
|
|
|
WCHAR DstPath[MAX_PATH];
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
DPRINT("WritePartitions() Disk: %lu\n", DiskEntry->DiskNumber);
|
|
|
|
|
2019-02-24 18:04:57 +00:00
|
|
|
/* If the disk is not dirty, there is nothing to do */
|
|
|
|
if (!DiskEntry->Dirty)
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
|
2017-05-31 01:43:12 +00:00
|
|
|
RtlStringCchPrintfW(DstPath, ARRAYSIZE(DstPath),
|
|
|
|
L"\\Device\\Harddisk%lu\\Partition0",
|
|
|
|
DiskEntry->DiskNumber);
|
|
|
|
RtlInitUnicodeString(&Name, DstPath);
|
2017-12-23 19:17:38 +00:00
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&Name,
|
2017-12-23 19:17:38 +00:00
|
|
|
OBJ_CASE_INSENSITIVE,
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
Status = NtOpenFile(&FileHandle,
|
|
|
|
GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE,
|
|
|
|
&ObjectAttributes,
|
|
|
|
&Iosb,
|
|
|
|
0,
|
|
|
|
FILE_SYNCHRONOUS_IO_NONALERT);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtOpenFile() failed (Status %lx)\n", Status);
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef DUMP_PARTITION_TABLE
|
|
|
|
DumpPartitionTable(DiskEntry);
|
|
|
|
#endif
|
|
|
|
|
2018-01-28 22:24:06 +00:00
|
|
|
//
|
|
|
|
// FIXME: We first *MUST* use IOCTL_DISK_CREATE_DISK to initialize
|
|
|
|
// the disk in MBR or GPT format in case the disk was not initialized!!
|
|
|
|
// For this we must ask the user which format to use.
|
|
|
|
//
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
/* Save the original partition count to be restored later (see comment below) */
|
|
|
|
PartitionCount = DiskEntry->LayoutBuffer->PartitionCount;
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Set the new disk layout and retrieve its updated version with
|
|
|
|
* new partition numbers for the new partitions. The PARTMGR will
|
|
|
|
* automatically notify the MOUNTMGR of new or deleted volumes. */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
BufferSize = sizeof(DRIVE_LAYOUT_INFORMATION) +
|
2018-11-22 02:26:47 +00:00
|
|
|
((PartitionCount - 1) * sizeof(PARTITION_INFORMATION));
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = NtDeviceIoControlFile(FileHandle,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
&Iosb,
|
|
|
|
IOCTL_DISK_SET_DRIVE_LAYOUT,
|
|
|
|
DiskEntry->LayoutBuffer,
|
|
|
|
BufferSize,
|
2018-11-22 02:26:47 +00:00
|
|
|
DiskEntry->LayoutBuffer,
|
|
|
|
BufferSize);
|
|
|
|
NtClose(FileHandle);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* IOCTL_DISK_SET_DRIVE_LAYOUT calls IoWritePartitionTable(), which converts
|
|
|
|
* DiskEntry->LayoutBuffer->PartitionCount into a partition *table* count,
|
|
|
|
* where such a table is expected to enumerate up to 4 partitions:
|
|
|
|
* partition *table* count == ROUND_UP(PartitionCount, 4) / 4 .
|
|
|
|
* Due to this we need to restore the original PartitionCount number.
|
|
|
|
*/
|
|
|
|
DiskEntry->LayoutBuffer->PartitionCount = PartitionCount;
|
|
|
|
|
|
|
|
/* Check whether the IOCTL_DISK_SET_DRIVE_LAYOUT call succeeded */
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("IOCTL_DISK_SET_DRIVE_LAYOUT failed (Status 0x%08lx)\n", Status);
|
2018-11-22 02:26:47 +00:00
|
|
|
return Status;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
2018-11-22 02:26:47 +00:00
|
|
|
#ifdef DUMP_PARTITION_TABLE
|
|
|
|
DumpPartitionTable(DiskEntry);
|
|
|
|
#endif
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Update the partition numbers and device names */
|
2018-11-22 02:26:47 +00:00
|
|
|
|
|
|
|
/* Update the primary partition table */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (ListEntry = DiskEntry->PrimaryPartListHead.Flink;
|
|
|
|
ListEntry != &DiskEntry->PrimaryPartListHead;
|
|
|
|
ListEntry = ListEntry->Flink)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(ListEntry, PARTENTRY, ListEntry);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!PartEntry->IsPartitioned)
|
|
|
|
continue;
|
|
|
|
ASSERT(PartEntry->PartitionType != PARTITION_ENTRY_UNUSED);
|
2018-11-22 02:26:47 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/*
|
|
|
|
* Initialize the partition's number and its device name only
|
|
|
|
* if the partition was new. Note that the partition number
|
|
|
|
* should not change if this partition has not been deleted
|
|
|
|
* during repartitioning.
|
|
|
|
*/
|
|
|
|
// FIXME: Our PartMgr currently returns modified numbers
|
|
|
|
// in the layout, this needs to be investigated and fixed.
|
|
|
|
if (PartEntry->New)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
|
|
|
PartitionInfo = &DiskEntry->LayoutBuffer->PartitionEntry[PartEntry->PartitionIndex];
|
|
|
|
PartEntry->PartitionNumber = PartitionInfo->PartitionNumber;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
InitPartitionDeviceName(PartEntry);
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PartEntry->New = FALSE;
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Update the logical partition table */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (ListEntry = DiskEntry->LogicalPartListHead.Flink;
|
|
|
|
ListEntry != &DiskEntry->LogicalPartListHead;
|
|
|
|
ListEntry = ListEntry->Flink)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
|
|
|
PartEntry = CONTAINING_RECORD(ListEntry, PARTENTRY, ListEntry);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!PartEntry->IsPartitioned)
|
|
|
|
continue;
|
|
|
|
ASSERT(PartEntry->PartitionType != PARTITION_ENTRY_UNUSED);
|
2018-11-22 02:26:47 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* See comment above */
|
|
|
|
if (PartEntry->New)
|
2018-11-22 02:26:47 +00:00
|
|
|
{
|
|
|
|
PartitionInfo = &DiskEntry->LayoutBuffer->PartitionEntry[PartEntry->PartitionIndex];
|
|
|
|
PartEntry->PartitionNumber = PartitionInfo->PartitionNumber;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
InitPartitionDeviceName(PartEntry);
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PartEntry->New = FALSE;
|
2018-11-22 02:26:47 +00:00
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
//
|
|
|
|
// NOTE: Originally (see r40437), we used to install here also a new MBR
|
|
|
|
// for this disk (by calling InstallMbrBootCodeToDisk), only if:
|
[SETUPLIB][USETUP] Improve disk HW numbering, removable disk support, and "super-floppy" partitioning.
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.
2019-03-11 23:13:25 +00:00
|
|
|
// DiskEntry->NewDisk == TRUE and DiskEntry->HwDiskNumber == 0.
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
// Then after that, both DiskEntry->NewDisk and DiskEntry->NoMbr were set
|
|
|
|
// to FALSE. In the other place (in usetup.c) where InstallMbrBootCodeToDisk
|
|
|
|
// was called too, the installation test was modified by checking whether
|
|
|
|
// DiskEntry->NoMbr was TRUE (instead of NewDisk).
|
|
|
|
//
|
|
|
|
|
2020-11-24 03:34:56 +00:00
|
|
|
// HACK: Parts of FIXMEs described above: (Re)set the PartitionStyle to MBR.
|
|
|
|
DiskEntry->DiskStyle = PARTITION_STYLE_MBR;
|
|
|
|
|
2019-02-24 18:04:57 +00:00
|
|
|
/* The layout has been successfully updated, the disk is not dirty anymore */
|
|
|
|
DiskEntry->Dirty = FALSE;
|
2018-11-22 02:26:47 +00:00
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
WritePartitionsToDisk(
|
|
|
|
IN PPARTLIST List)
|
|
|
|
{
|
2019-02-24 18:04:57 +00:00
|
|
|
NTSTATUS Status;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
PDISKENTRY DiskEntry;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PVOLENTRY Volume;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!List)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return TRUE;
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Write all the partitions to all the disks */
|
2018-12-08 23:36:56 +00:00
|
|
|
for (Entry = List->DiskListHead.Flink;
|
|
|
|
Entry != &List->DiskListHead;
|
|
|
|
Entry = Entry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
|
|
|
DiskEntry = CONTAINING_RECORD(Entry, DISKENTRY, ListEntry);
|
|
|
|
|
2018-12-13 23:30:12 +00:00
|
|
|
if (DiskEntry->DiskStyle == PARTITION_STYLE_GPT)
|
|
|
|
{
|
|
|
|
DPRINT("GPT-partitioned disk detected, not currently supported by SETUP!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
if (DiskEntry->Dirty != FALSE)
|
|
|
|
{
|
2019-02-24 18:04:57 +00:00
|
|
|
Status = WritePartitions(DiskEntry);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("WritePartitionsToDisk() failed to update disk %lu, Status 0x%08lx\n",
|
|
|
|
DiskEntry->DiskNumber, Status);
|
|
|
|
}
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* The PARTMGR should have notified the MOUNTMGR that new volumes
|
|
|
|
* associated with the new partitions had to be created */
|
|
|
|
|
|
|
|
/* Assign valid device names to new volumes */
|
|
|
|
for (Entry = List->VolumesList.Flink;
|
|
|
|
Entry != &List->VolumesList;
|
|
|
|
Entry = Entry->Flink)
|
|
|
|
{
|
|
|
|
Volume = CONTAINING_RECORD(Entry, VOLENTRY, ListEntry);
|
|
|
|
InitVolumeDeviceName(Volume);
|
|
|
|
}
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @brief
|
|
|
|
* Assign a "\DosDevices\#:" mount point drive letter to a disk partition or
|
|
|
|
* volume, specified by a given disk signature and starting partition offset.
|
|
|
|
**/
|
|
|
|
static BOOLEAN
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
SetMountedDeviceValue(
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
_In_ PVOLENTRY Volume)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PPARTENTRY PartEntry = Volume->PartEntry;
|
|
|
|
WCHAR Letter = Volume->Info.DriveLetter;
|
2019-12-26 16:16:04 +00:00
|
|
|
NTSTATUS Status;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
2019-12-26 16:16:04 +00:00
|
|
|
UNICODE_STRING KeyName = RTL_CONSTANT_STRING(L"SYSTEM\\MountedDevices");
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
UNICODE_STRING ValueName;
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
WCHAR Buffer[16];
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
HANDLE KeyHandle;
|
2019-12-26 16:16:04 +00:00
|
|
|
REG_DISK_MOUNT_INFO MountInfo;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Ignore no letter */
|
|
|
|
if (!Letter)
|
|
|
|
return TRUE;
|
|
|
|
|
|
|
|
RtlStringCchPrintfW(Buffer, _countof(Buffer),
|
2018-01-28 22:24:06 +00:00
|
|
|
L"\\DosDevices\\%c:", Letter);
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
RtlInitUnicodeString(&ValueName, Buffer);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
2019-12-26 16:16:04 +00:00
|
|
|
GetRootKeyByPredefKey(HKEY_LOCAL_MACHINE, NULL),
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
NULL);
|
2017-12-23 19:17:38 +00:00
|
|
|
|
2019-12-26 16:16:04 +00:00
|
|
|
Status = NtOpenKey(&KeyHandle,
|
|
|
|
KEY_ALL_ACCESS,
|
|
|
|
&ObjectAttributes);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
Status = NtCreateKey(&KeyHandle,
|
|
|
|
KEY_ALL_ACCESS,
|
|
|
|
&ObjectAttributes,
|
|
|
|
0,
|
|
|
|
NULL,
|
|
|
|
REG_OPTION_NON_VOLATILE,
|
|
|
|
NULL);
|
|
|
|
}
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtCreateKey() failed (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
MountInfo.Signature = PartEntry->DiskEntry->LayoutBuffer->Signature;
|
|
|
|
MountInfo.StartingOffset = GetPartEntryOffsetInBytes(PartEntry);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
Status = NtSetValueKey(KeyHandle,
|
|
|
|
&ValueName,
|
|
|
|
0,
|
|
|
|
REG_BINARY,
|
|
|
|
(PVOID)&MountInfo,
|
|
|
|
sizeof(MountInfo));
|
|
|
|
NtClose(KeyHandle);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtSetValueKey() failed (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
SetMountedDeviceValues(
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
_In_ PPARTLIST List)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
PLIST_ENTRY Entry;
|
|
|
|
PVOLENTRY Volume;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
if (!List)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
return FALSE;
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
for (Entry = List->VolumesList.Flink;
|
|
|
|
Entry != &List->VolumesList;
|
|
|
|
Entry = Entry->Flink)
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
{
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
Volume = CONTAINING_RECORD(Entry, VOLENTRY, ListEntry);
|
2019-02-24 18:04:57 +00:00
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Assign a "\DosDevices\#:" mount point to this volume */
|
|
|
|
if (!SetMountedDeviceValue(Volume))
|
|
|
|
return FALSE;
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
2020-11-24 00:49:41 +00:00
|
|
|
SetMBRPartitionType(
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
IN PPARTENTRY PartEntry,
|
|
|
|
IN UCHAR PartitionType)
|
|
|
|
{
|
|
|
|
PDISKENTRY DiskEntry = PartEntry->DiskEntry;
|
|
|
|
|
2020-11-24 00:49:41 +00:00
|
|
|
ASSERT(DiskEntry->DiskStyle == PARTITION_STYLE_MBR);
|
|
|
|
|
[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.
2024-05-18 21:09:16 +00:00
|
|
|
/* Nothing to do if we assign the same type */
|
|
|
|
if (PartitionType == PartEntry->PartitionType)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// TODO: We might need to remount the associated basic volume...
|
|
|
|
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
PartEntry->PartitionType = PartitionType;
|
|
|
|
|
|
|
|
DiskEntry->Dirty = TRUE;
|
|
|
|
DiskEntry->LayoutBuffer->PartitionEntry[PartEntry->PartitionIndex].PartitionType = PartitionType;
|
2018-11-22 02:26:47 +00:00
|
|
|
DiskEntry->LayoutBuffer->PartitionEntry[PartEntry->PartitionIndex].RecognizedPartition = IsRecognizedPartition(PartitionType);
|
[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
2017-05-17 23:37:41 +00:00
|
|
|
DiskEntry->LayoutBuffer->PartitionEntry[PartEntry->PartitionIndex].RewritePartition = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* EOF */
|