Intravision/reactos
1
0
Fork 0
mirror of https://github.com/reactos/reactos.git synced 2024-12-29 02:25:17 +00:00
Code Issues Projects Releases Packages Wiki Activity
reactos/base/setup/lib/fsutil.h

219 lines
5 KiB
C
Raw Normal View History

[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark 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][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
* LICENSE: GPL-2.0-or-later (https://spdx.org/licenses/GPL-2.0-or-later)
* PURPOSE: Filesystem Format and ChkDsk support functions
* COPYRIGHT: Copyright 2003-2019 Casper S. Hornstrup <chorns@users.sourceforge.net>
* Copyright 2017-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
*/
[USETUP][SETUPLIB] Move the bootsup.c code into the setuplib, and perform the necessary adjustments. Move the bootsup.c code into the setuplib, as the code is generic enough to be used by both USETUP and the 1st-stage GUI installer. svn path=/branches/setup_improvements/; revision=75674
2017-08-26 11:42:32 +00:00
#pragma once
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark 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 <fmifs/fmifs.h>
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
/** QueryAvailableFileSystemFormat() **/
BOOLEAN
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
GetRegisteredFileSystems(
IN ULONG Index,
OUT PCWSTR* FileSystemName);
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark 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] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
/** ChkdskEx() **/
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
ChkdskFileSystem_UStr(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
_In_ PUNICODE_STRING DriveRoot,
_In_ PCWSTR FileSystemName,
_In_ BOOLEAN FixErrors,
_In_ BOOLEAN Verbose,
_In_ BOOLEAN CheckOnlyIfDirty,
_In_ BOOLEAN ScanDrive,
_In_opt_ PFMIFSCALLBACK Callback);
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
ChkdskFileSystem(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
_In_ PCWSTR DriveRoot,
_In_ PCWSTR FileSystemName,
_In_ BOOLEAN FixErrors,
_In_ BOOLEAN Verbose,
_In_ BOOLEAN CheckOnlyIfDirty,
_In_ BOOLEAN ScanDrive,
_In_opt_ PFMIFSCALLBACK Callback);
[SETUPLIB][USETUP] Introduce a 'SetupLib' library. CORE-13544 - Create the beginnings of a "setuplib" library, whose aim is to be shared between the (currently existing) 1st-stage text-mode installer, and the (future) 1st-stage GUI installer. - Finish to split the GenList and PartList codes into their UI part, which remain in usetup, and their algorithmic part, which go into setuplib. - Move SetMountedDeviceValue into the PartList module. - Split the FileSystem list code into its UI and the algorithmic part (which goes into setuplib under the name fsutil.c). * The algo part is meant to be able to manage the filesystems available on the running system, similarly to what is mostly done (in scattered form) in fmifs, format, chkdsk / autochk codes... It also manages the partition filesystem recognition, using OS routines. * The UI part manages the FS list as it appears on screen, showing only the possible FSes that can be used to format the selected partition (a bit similar to what we do in the shell32's drive.c, etc...). - Adapt the calling code to these changes. - Remove some "host" code that was dating back from the dark 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] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
/** FormatEx() **/
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
FormatFileSystem_UStr(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
_In_ PUNICODE_STRING DriveRoot,
_In_ PCWSTR FileSystemName,
_In_ FMIFS_MEDIA_FLAG MediaFlag,
_In_opt_ PUNICODE_STRING Label,
_In_ BOOLEAN QuickFormat,
_In_ ULONG ClusterSize,
_In_opt_ PFMIFSCALLBACK Callback);
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
FormatFileSystem(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
_In_ PCWSTR DriveRoot,
_In_ PCWSTR FileSystemName,
_In_ FMIFS_MEDIA_FLAG MediaFlag,
_In_opt_ PCWSTR Label,
_In_ BOOLEAN QuickFormat,
_In_ ULONG ClusterSize,
_In_opt_ PFMIFSCALLBACK Callback);
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
[SETUPLIB] Code re-organization in bootsup.c and fsutil.c. - Move the actual VBR bootcode installation helpers into fsutil.c (they depend on the selected filesystem). - Introduce InstallBootCodeToDisk() and InstallBootCodeToFile() and bootcode.c helpers, in order to replace the several functions that were duplicating the same code.
2020-10-17 18:29:47 +00:00
//
// Bootsector routines
//
#define FAT_BOOTSECTOR_SIZE (1 * SECTORSIZE)
#define FAT32_BOOTSECTOR_SIZE (1 * SECTORSIZE) // Counts only the primary sector.
#define BTRFS_BOOTSECTOR_SIZE (3 * SECTORSIZE)
[SETUPLIB] Add NTFS boot support. (#3778)
2022-10-19 00:02:24 +00:00
#define NTFS_BOOTSECTOR_SIZE (16 * SECTORSIZE)
[SETUPLIB] Code re-organization in bootsup.c and fsutil.c. - Move the actual VBR bootcode installation helpers into fsutil.c (they depend on the selected filesystem). - Introduce InstallBootCodeToDisk() and InstallBootCodeToFile() and bootcode.c helpers, in order to replace the several functions that were duplicating the same code.
2020-10-17 18:29:47 +00:00
typedef NTSTATUS
(/*NTAPI*/ *PFS_INSTALL_BOOTCODE)(
IN PCWSTR SrcPath, // Bootsector source file (on the installation medium)
IN HANDLE DstPath, // Where to save the bootsector built from the source + partition information
IN HANDLE RootPartition); // Partition holding the (old) bootsector data information
NTSTATUS
[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on. The formatter will select it anyway as soon as the partition size permits it. We make it available internally however so as to "emulate" FMIFS functionality. Now rely on the partition filesystem for InstallVBRToPartition() instead of the unreliable and deprecated partition type.
2020-10-19 21:49:26 +00:00
InstallFatBootCode(
[SETUPLIB] Code re-organization in bootsup.c and fsutil.c. - Move the actual VBR bootcode installation helpers into fsutil.c (they depend on the selected filesystem). - Introduce InstallBootCodeToDisk() and InstallBootCodeToFile() and bootcode.c helpers, in order to replace the several functions that were duplicating the same code.
2020-10-17 18:29:47 +00:00
IN PCWSTR SrcPath,
IN HANDLE DstPath,
IN HANDLE RootPartition);
[USETUP][SETUPLIB] Continue hiding the FAT32 format in the format list, but take it into account anyway later on. The formatter will select it anyway as soon as the partition size permits it. We make it available internally however so as to "emulate" FMIFS functionality. Now rely on the partition filesystem for InstallVBRToPartition() instead of the unreliable and deprecated partition type.
2020-10-19 21:49:26 +00:00
#define InstallFat12BootCode InstallFatBootCode
#define InstallFat16BootCode InstallFatBootCode
[SETUPLIB] Code re-organization in bootsup.c and fsutil.c. - Move the actual VBR bootcode installation helpers into fsutil.c (they depend on the selected filesystem). - Introduce InstallBootCodeToDisk() and InstallBootCodeToFile() and bootcode.c helpers, in order to replace the several functions that were duplicating the same code.
2020-10-17 18:29:47 +00:00
NTSTATUS
InstallFat32BootCode(
IN PCWSTR SrcPath,
IN HANDLE DstPath,
IN HANDLE RootPartition);
NTSTATUS
InstallBtrfsBootCode(
IN PCWSTR SrcPath,
IN HANDLE DstPath,
IN HANDLE RootPartition);
[SETUPLIB] Add NTFS boot support. (#3778)
2022-10-19 00:02:24 +00:00
NTSTATUS
InstallNtfsBootCode(
IN PCWSTR SrcPath,
IN HANDLE DstPath,
IN HANDLE RootPartition);
[SETUPLIB] Code re-organization in bootsup.c and fsutil.c. - Move the actual VBR bootcode installation helpers into fsutil.c (they depend on the selected filesystem). - Introduce InstallBootCodeToDisk() and InstallBootCodeToFile() and bootcode.c helpers, in order to replace the several functions that were duplicating the same code.
2020-10-17 18:29:47 +00:00
[SETUPLIB][USETUP] Factor out the usage of FS provider structures. Similarly to FMIFS this structure should be private. Instead file-system names are passed to the helper functions, allowing to use the names returned by the FS drivers. The names are then internally mapped to the corresponding FS providers. In particular this allows to handle the "RAW" file-system and to assign the 'Unformatted' flag to partitions having this FS. Finally this helps us refining the checks performed to see whether the current "active" system partition uses a supported file-system.
2019-02-24 16:52:33 +00:00
//
// Formatting routines
//
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers so that they wrap the needed init steps for formatting/chkdsk'ing. These helpers now accept a PPARTENTRY, together with the usual formatting/chkdsk parameters. The helpers now determine the actual NT path to use, and can perform the init steps on the partition before performing the actual operation. In particular, FormatPartition() is now made GPT-compliant. The partition type retrieved by FileSystemToMBRPartitionType() is now used as a hint for choosing FAT32 over FAT12/16, and only in the case of a MBR partition that is *NOT* a recognized OEM partition, it is used for updating the corresponding partition type. (OEM partitions must retain their original type.) The OEM partition types we (and NT) can recognize are specified e.g. in the Microsoft Open-Specification [MS-DMRP] Appendix B https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dmrp/5f5043a3-9e6d-40cc-a05b-1a4a3617df32 Introduce an IsOEMPartition() macro to help checking for these types (its name is based on the Is***Partition() macros from ntdddisk.h, and from a dmdskmgr.dll export of similar name).
2020-11-24 01:26:52 +00:00
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers so that they wrap the needed init steps for formatting/chkdsk'ing. These helpers now accept a PPARTENTRY, together with the usual formatting/chkdsk parameters. The helpers now determine the actual NT path to use, and can perform the init steps on the partition before performing the actual operation. In particular, FormatPartition() is now made GPT-compliant. The partition type retrieved by FileSystemToMBRPartitionType() is now used as a hint for choosing FAT32 over FAT12/16, and only in the case of a MBR partition that is *NOT* a recognized OEM partition, it is used for updating the corresponding partition type. (OEM partitions must retain their original type.) The OEM partition types we (and NT) can recognize are specified e.g. in the Microsoft Open-Specification [MS-DMRP] Appendix B https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dmrp/5f5043a3-9e6d-40cc-a05b-1a4a3617df32 Introduce an IsOEMPartition() macro to help checking for these types (its name is based on the Is***Partition() macros from ntdddisk.h, and from a dmdskmgr.dll export of similar name).
2020-11-24 01:26:52 +00:00
ChkdskPartition(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
_In_ PPARTENTRY PartEntry,
_In_ BOOLEAN FixErrors,
_In_ BOOLEAN Verbose,
_In_ BOOLEAN CheckOnlyIfDirty,
_In_ BOOLEAN ScanDrive,
_In_opt_ PFMIFSCALLBACK Callback);
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +00:00
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers so that they wrap the needed init steps for formatting/chkdsk'ing. These helpers now accept a PPARTENTRY, together with the usual formatting/chkdsk parameters. The helpers now determine the actual NT path to use, and can perform the init steps on the partition before performing the actual operation. In particular, FormatPartition() is now made GPT-compliant. The partition type retrieved by FileSystemToMBRPartitionType() is now used as a hint for choosing FAT32 over FAT12/16, and only in the case of a MBR partition that is *NOT* a recognized OEM partition, it is used for updating the corresponding partition type. (OEM partitions must retain their original type.) The OEM partition types we (and NT) can recognize are specified e.g. in the Microsoft Open-Specification [MS-DMRP] Appendix B https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dmrp/5f5043a3-9e6d-40cc-a05b-1a4a3617df32 Introduce an IsOEMPartition() macro to help checking for these types (its name is based on the Is***Partition() macros from ntdddisk.h, and from a dmdskmgr.dll export of similar name).
2020-11-24 01:26:52 +00:00
NTSTATUS
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Cleanup some code in USETUP. Redefine FormatPartition() and ChkdskPartition() helpers so that they wrap the needed init steps for formatting/chkdsk'ing. These helpers now accept a PPARTENTRY, together with the usual formatting/chkdsk parameters. The helpers now determine the actual NT path to use, and can perform the init steps on the partition before performing the actual operation. In particular, FormatPartition() is now made GPT-compliant. The partition type retrieved by FileSystemToMBRPartitionType() is now used as a hint for choosing FAT32 over FAT12/16, and only in the case of a MBR partition that is *NOT* a recognized OEM partition, it is used for updating the corresponding partition type. (OEM partitions must retain their original type.) The OEM partition types we (and NT) can recognize are specified e.g. in the Microsoft Open-Specification [MS-DMRP] Appendix B https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dmrp/5f5043a3-9e6d-40cc-a05b-1a4a3617df32 Introduce an IsOEMPartition() macro to help checking for these types (its name is based on the Is***Partition() macros from ntdddisk.h, and from a dmdskmgr.dll export of similar name).
2020-11-24 01:26:52 +00:00
FormatPartition(
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
_In_ PPARTENTRY PartEntry,
_In_ PCWSTR FileSystemName,
_In_ FMIFS_MEDIA_FLAG MediaFlag,
_In_opt_ PCWSTR Label,
_In_ BOOLEAN QuickFormat,
_In_ ULONG ClusterSize,
_In_opt_ PFMIFSCALLBACK Callback);
//
// FileSystem Volume Operations Queue
//
typedef enum _FSVOLNOTIFY
{
FSVOLNOTIFY_STARTQUEUE = 0,
FSVOLNOTIFY_ENDQUEUE,
FSVOLNOTIFY_STARTSUBQUEUE,
FSVOLNOTIFY_ENDSUBQUEUE,
// FSVOLNOTIFY_STARTPARTITION, FSVOLNOTIFY_ENDPARTITION,
FSVOLNOTIFY_PARTITIONERROR,
FSVOLNOTIFY_STARTFORMAT,
FSVOLNOTIFY_ENDFORMAT,
FSVOLNOTIFY_FORMATERROR,
FSVOLNOTIFY_STARTCHECK,
FSVOLNOTIFY_ENDCHECK,
FSVOLNOTIFY_CHECKERROR,
/**/ChangeSystemPartition/**/ // FIXME: Deprecate!
} FSVOLNOTIFY;
typedef enum _FSVOL_OP
{
/* Operations ****/
FSVOL_FORMAT = 0,
FSVOL_CHECK,
/* Response actions ****/
FSVOL_ABORT = 0,
FSVOL_DOIT,
FSVOL_RETRY = FSVOL_DOIT,
FSVOL_SKIP,
} FSVOL_OP;
typedef struct _FORMAT_VOLUME_INFO
{
[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] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
// PCWSTR NtPathPartition;
NTSTATUS ErrorStatus;
/* Input information given by the 'FSVOLNOTIFY_STARTFORMAT' step ****/
PCWSTR FileSystemName;
FMIFS_MEDIA_FLAG MediaFlag;
PCWSTR Label;
BOOLEAN QuickFormat;
ULONG ClusterSize;
PFMIFSCALLBACK Callback;
} FORMAT_VOLUME_INFO, *PFORMAT_VOLUME_INFO;
typedef struct _CHECK_VOLUME_INFO
{
[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] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
// PCWSTR NtPathPartition;
NTSTATUS ErrorStatus;
/* Input information given by the 'FSVOLNOTIFY_STARTCHECK' step ****/
BOOLEAN FixErrors;
BOOLEAN Verbose;
BOOLEAN CheckOnlyIfDirty;
BOOLEAN ScanDrive;
PFMIFSCALLBACK Callback;
} CHECK_VOLUME_INFO, *PCHECK_VOLUME_INFO;
typedef FSVOL_OP
(CALLBACK *PFSVOL_CALLBACK)(
_In_opt_ PVOID Context,
_In_ FSVOLNOTIFY FormatStatus,
_In_ ULONG_PTR Param1,
_In_ ULONG_PTR Param2);
BOOLEAN
[SETUPLIB][REACTOS][USETUP] Turn setuplib into a DLL shared between TUI and GUI 1st-stage setups (#7523) CORE-13525 Notes: - Most of the exported functions have been turned from default cdecl to explicit stdcall / "NTAPI". - The two InitializeSetup() phases have been collapsed to make the initialization simpler. Average reductions (percentages; see PR #7523 for actual numbers): x86 Debug builds: reactos.exe: 35.1% smss.exe : 39.8% Total (including setuplib.dll): 17.9% x86 Release builds: reactos.exe: 22.3% smss.exe : 25.0% Total (including setuplib.dll): 10.6% x64 Debug builds: reactos.exe: 40.6% smss.exe : 41.6% Total (including setuplib.dll): 20.0% x64 Release builds: reactos.exe: 22.8% smss.exe : 22.3% Total (including setuplib.dll): 10.1%
2024-11-22 20:45:06 +00:00
NTAPI
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
FsVolCommitOpsQueue(
_In_ PPARTLIST PartitionList,
[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 SystemVolume,
_In_ PVOLENTRY InstallVolume,
[SETUPLIB][USETUP] Isolate and decouple the filesystem operations code from the UI (#7049) The idea is reminiscent of the SetupCommitFileQueue() function: filesystem volume operations are "queued" and processed via a "commit queue". The commit queue uses a user-specified callback, that is used to interact with the user whenever an operation (filesystem formatting, checking) is started, ended, or fails, for example by displaying appropriate UI screens and choices, etc.
2020-11-23 03:38:51 +00:00
_In_opt_ PFSVOL_CALLBACK FsVolCallback,
_In_opt_ PVOID Context);
[SETUPLIB] Consolidate the FsUtil and PartList modules of the SetupLib. - Add a PreparePartitionForFormatting routine that sets the partition ID depending on the chosen filesystem. - The 'FORMATMACHINESTATE FormatState' machine-state and the 'TempPartition' members of the partition list structure is purely a USETUP convenience, so remove them from the PARTLIST structure and move them back into USETUP. - Attempt to recognize the filesystem (set the 'FileSystem' member of PARTENTRY) of partitions we are adding into the PARTLIST list. - Fix the return value of the SelectPartition function, which is by the way completely broken (it doesn't do what it is supposed to do; alternatively its naming is completely wrong...). svn path=/branches/setup_improvements/; revision=74572 svn path=/branches/setup_improvements/; revision=74573
2017-05-17 23:31:52 +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
/* EOF */
Reference in a new issue Copy permalink