URLs are getting old. We have to
update URLs for documentation
purpose.
JIRA issue: CORE-19963
- Refresh old URLs.
- Add " (DEAD_LINK)" labels
to dead links.
- Use MS Learn links rather
than MSDN ones.
- Some dead links revived by
Web Archive.
- Don't change Wine Tests
and Wine Sync.
- Don't change 3rd party libraries.
- Don't append "redirected" labels.
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%
Fixes previous attempt at commit 0ca4e6dcf, which was reverted by commit
bbdcc14b1 because the partitioning checks mistook unpartitioned disks as
GPT.
Addendum to commit 99f0937fd.
The partition-creation checks are unified for these partitions into one
single function. To prepare for GPT support, the specifics are put into
a separate MBRPartitionCreateChecks() helper, called for MBR disks by the
upper-level function. GPT disks will have a similar helper in the future.
Addendum to commmit 99f0937fd.
The partition-creation checks are unified for these partitions into one
single function. To prepare for GPT support, the specifics are put into
a separate MBRPartitionCreateChecks() helper, called for MBR disks by the
upper-level function. GPT disks will have a similar helper in the future.
CORE-13525
- Newly-created partitions and unpartitioned space ar reinserted
or updated in correct order in the tree-list. Volume-creation
information data associated with the tree items is persisted
across operations.
- Reliably delete data associated to tree-list items via the
TVN_DELETEITEM notification.
This allows simplifying the cleanup function; keeping simple
the code that deletes items when deleting partitions, etc.
- Make the PrintPartitionData() function call itself recursively on
extended partitions to display the sub-list of logical partitions.
- Handle the new partition size in MB the same way as in USETUP.
- Allow existing partitions/volumes to be re-formatted, using
common code with the partition creation dialog.
- Allow selecting unpartitioned space or non-formatted partitions
for installing ReactOS: unused space will automatically be
partitioned and non-formatted partitions formatted (the user
is prompted for choosing the file system).
- Correctly zero the progress-bar position when starting file copy.
- Add missing file copy error handler in FileCopyCallback:
just copying what USETUP does.
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.
Addendum to commit 32e6eed760 (r63715)
CORE-5982
The function assumed that the directory path name to be created
always starts with a harddisk-partition root device name of the form:
\Device\HarddiskX\PartitionY\
Indeed, it can be (when using the volume manager) of the form:
\Device\HarddiskVolumeN\
and could even have a different format if trying to install ReactOS
on an external removable drive or other weird device.
Since the format of this prefix is not 100% always the same,
a different way to create the sub-directories is needed.
The nested-directory creation algorithm is changed as follows:
Suppose that the directory to be created is:
\Device\HarddiskVolume1\ReactOS\system32\drivers
The function first loops backwards each path component in order
to find the deepest existing sub-directory: it will try to verify
whether each of the following sub-directories exist, successively:
\Device\HarddiskVolume1\ReactOS\system32\drivers
\Device\HarddiskVolume1\ReactOS\system32\
\Device\HarddiskVolume1\ReactOS\
\Device\HarddiskVolume1\
(Notice the trailing path separators kept in this step.)
In principle, this root device FS directory must exist (since the
volume has been formatted previously). Once found, the function will
then create each of the sub-directories in turn:
\Device\HarddiskVolume1\ReactOS
\Device\HarddiskVolume1\ReactOS\system32
\Device\HarddiskVolume1\ReactOS\system32\drivers
----
An alternative to the fix could be to always specify the root device
name in a separate parameter, but this hasn't been pursued here so as
to not modify all the callers of this function.
It was introduced in commit 703eb5e8c9 (r7756) in order to hack around
the "dot"-path added in the reactos.dff generator file by the earlier
commit 3bd689f185 (r7269).
Its aim was to describe the installation directory itself, instead of
one of its sub-directories.
That _invalid_ "dot"-path was removed later by commit 027e2bfa3a (r15423);
however the '\.' hack stayed for quite a while in our code.
The correct way to describe the installation directory itself is to use
instead "\", compatible with Windows' setup, as was originally done in
txtsetup.sif, and fixed in reactos.dff(.in) in commit 97bb83fcd9 (r66604).
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.
See commits ebcf3cf38 and c9c6902f0 (PR #5837)
In addition, correctly set the type of extended partition being used,
depending on whether it is contained below or above the 1024-cylinder
boundary (tested on NT).
CORE-19575
For the time being, don't add read-only attribute for ease of testing
and modifying files, but it won't always stay this way.
For example, Windows sets its boot.ini (as well as NTLDR, NTDETECT.COM
etc.) as read-only (+ hidden and system) during its 1st-stage setup.
2nd-stage setup makes some adjustments in boot.ini but doesn't restore
its read-only attribute.
Windows tools that can modify boot.ini (i.e. msconfig.exe, bootcfg.exe,
and sysdm.cpl) **ALL** know how to remove the read-only attribute for
modifying boot.ini, before restoring it if needed.
The BootDrive and BootPartition values are deprecated, and support
for them will soon be removed from FreeLoader.
Add an helper function to migrate these values during ReactOS
(re)installation / update.
The support is so far enabled only for INI files (freeldr.ini, boot.ini).
May be subject to further improvements in the future.
Usage examples:
- When finding existing ReactOS or Windows installations, the boot store
should exist and is opened in read-only mode. Closing the boot store
doesn't store any temporary modifications made to it.
- When doing a clean installation, freeldr.ini is created in read-write
access.
- When installing with an existing freeldr.ini or boot.ini, they are
opened as existing files in read-write access.
- QueryBootStoreOptions(): De-duplicate code.
- SetBootStoreOpt(): Respect the FieldsToChange flag.
- BOOT_STORE_OPTIONS: Remove unused Version field and distinguish
between "Current" and "Next" BootEntryKey.
- If a section already exists, return the existing one. This allows
avoiding different section entries with the same name in the cache.
If an INI file has separate sections with the same name, their
contents (key-values) get merged into a unique section.
- If a key-value already exists, update its data value and return the
existing one. (Note that this may be subject to behaviour change in
the future.)
- Make the Create*Partition helpers take a size in bytes, not in sectors.
This allows them to be easier to use by the caller, alleviating the
need for making the size conversion into sectors. Instead it is done
internally by the helpers.
- Introduce helper macros to easily retrieve the size of a partition
entry or a disk in bytes, from their internal representation in number
of sectors.
- The 'AutoCreate' variable being USETUP-specific, remove it from the
PARTENTRY structure and use instead a flag set into the 'New' member.
- Rename IsDiskSizeValid to IsPartitionLargeEnough, to better describe
what the function is for.
Do not do that yet for extended partitions (containers).
This is possible, because when creating partitions, we do that on
unpartitioned space that is already "tagged" as either being "logical"
or not, and the partition style is inherited from that.
The resulting code is simpler, yet working as it should.
This will also help in the future for supporting other platforms, where
the concept of "primary", "extended" and "logical" partitions do not
exist (basically all platforms except BIOS-based PC-AT).
This includes:
- the default TimeText;
- the default colors.
They can however be changed by the user at one's convenience, by
explicitly specifying different values.
The upstream driver is not maintained and the file system itself
is in a semi-abandoned state.
Originally imported at 3a3ef631d1
The driver is written by Lee Jae-Hong, updated by Bo Brantén.
ReactOS porting made by Peter Hater and Pierre Schweitzer.
Follow updates at http://www.acc.umu.se/~bosse/
FS Recognizer code is left to keep the FS support as an
installable driver.
CORE-11040
The upstream driver is not maintained and the file system itself
is in a semi-abandoned state.
Originally imported at e308102f4a
The driver is written by Mark W Piper, updated by Bo Brantén.
ReactOS porting made by Peter Hater and Pierre Schweitzer.
Follow updates at http://www.acc.umu.se/~bosse/
FS Recognizer code is left to keep the FS support as an
installable driver.
CORE-11005
Add two hacks in UpdateDiskLayout() and WritePartitions() so that the
disk partition style is consistently set to a known value MBR, especially
when that disk was previously new and uninitialized (RAW).
A proper fix will be developed later when support for GPT is added.
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).
Instead of providing an MBR partition type to InferFileSystem(), make
it call IOCTL_DISK_GET_PARTITION_INFO(_EX) to determine whether the
partition pointed by the path/handle is MBR or GPT. Then, only if it's
MBR, we retrieve its partition type in order to "guess" an adequate file
system name, in case the latter was not recognized already via regular
ways (via GetFileSystemName() / NtQueryVolumeInformationFile()).
- Remove the GetFileSystemNameByHandle() and InferFileSystemByHandle()
functions. Instead, make the other GetFileSystemName*() and
InferFileSystem*() functions accept a HANDLE as an alternative to the
already-existing partition path string. These parameters are exclusive
to each other.
- Rename SetPartitionType() -> SetMBRPartitionType(),
and FileSystemToPartitionType() -> FileSystemToMBRPartitionType()
in order to really clarify what they do (since this code is meant
for MBR partitions only, not GPT ones).
