Instead link to cpprt. This fixes build with GCC 13, which generates symbols that conflict with __cxa_pure_virtual, if there is a pure virtual function in a vtable. Importing __cxa_pure_virtual from a library works for all versions of GCC.
Make these definitions compatible with the other ambient size_t and
(u)intptr_t types used in the rest of our code base.
This partly reverts the corresponding typedef changes from wine commit
d8ab5a14aa
"msvcrt: Use intptr_t or size_t instead of long where appropriate."
Refine the algorithm introduced in commit c560342f08 (r75667, r75676),
whereby the installation source path is based on the full image file path
of the installer program, and of the \SystemRoot symlink.
Also reverts commit 6f389a35db "Add a workaround for installing from USB drives"
CORE-17818
+ SAL2-annotate and add Doxygen comments.
----
In case the \SystemRoot full path prefixes the image file path,
use the resolved \SystemRoot as the installation source path.
Otherwise, use the image file path.
The \SystemRoot symlink target resolution needs full path reparsing,
because it can reference other symlinks. This is what happens, for
example when booting the installation from a removable hard-disk.
We can have:
\SystemRoot ---> \Device\Harddisk1\Partition1\ReactOS
and: \Device\Harddisk1\Partition1 ---> \Device\HarddiskVolume2
etc.
and we wish to resolve \SystemRoot to: \Device\HarddiskVolume2\ReactOS
instead of keeping the former version (using Harddisk1\Partition1).
We then verify whether it prefixes the image file path, which is
a fully reparsed path.
Based on the Doug Lyons' test in #7087, I found that my previous fix stopped working partially. Or rather, it would only work until the 32767 indexes were exhausted. It seems to me that the behavior of the bitfield has changed, because when I published the previous patch, it passed my tests.
- Bit array generates free ID cyclically, in the previous code after 32767 indexes expired the same index was returned, because of this the previous fix would stop working after expiration, so change the logic of calculating the next index.
- Change the index range to 256-32767 to match Windows, indexes 0-255 can theoretically be used as reserved for system purposes.
Addendum to fd327db20f. CORE-9141
According to tests, legacy fp state is not saved in kernel mode.
Also add an int 2c to the path that changes cs, as it should not be used and probably never will be.
CORE-13525
This is done so that the caller doesn't need to know details
about particular architecture specifics, like VBR, MBR etc.
Extra checks and specific handling is also performed for supporting
bootloader installation on removable media:
- verify whether the media is a floppy or some other removable media,
- depending on which, a suitable file system is chosen,
- and if the media is not a floppy, do the supplemental partition
verifications to determine whether the media is a "super-floppy"
(in the partitioning sense).
This function could be generalized later to copy other files necessary
for the bootloader; removing also the currently hardcoded placement in
the installation source directory, and instead, using a configurable
path (specified in txtsetup.sif); etc.
Adapted from a commit by Timo Kreuzer (see PR #7420)
Co-Authored-By: Timo Kreuzer <timo.kreuzer@reactos.org>
KeFlushQueuedDpcs is used by some drivers, when unloading or removing a device, to be sure no DPC is still running their code. On a UP system this can be done "inline", on an SMP system, it requires to send an IPI to each processor that has DPCs queued and also synchronize it with the calling thread, which is what KeSetSystemAffinityThread does implicitly: When a queued DPC was detected on a remote processor (implying that processor is currently running at DISPATCH_LEVEL or above), KeSetSystemAffinityThread will schedule the current thread on that processor and send a DPC interrupt. The remote processor will handle that DPC interrupt once it is back below DISPATCH_LEVEL. It will only run the current thread, after all queued DPCs (including threaded DPCs) have finished running.
- Use _alloca instead of non-standard alloca
- Use _TCHAR instead of non-standard TCHAR
- Use _off_t instead of deprecated off_t
- Use _O_BINARY instead of O_BINARY
* [MKISOFS] Fix Clang check for macOS platforms
On macOS, CMAKE_C_COMPILER_ID is "AppleClang". While certainly Clang,
this does not match the exact string "Clang" that is being checked for,
and as a result the warning flags guarded thereby are not passed to the
compiler. With this change CMake will recognize both Clang and AppleClang.
* Update sdk/tools/mkisofs/CMakeLists.txt
- The original code was just incrementing the reference counts (RefCounts)
of the device objects or the device/file handles, without decrementing
them when closing the handles. This is now fixed.
Notice the following:
* When opening a file on a device (disk), the device's (and its
handle's) RefCount is incremented, and the file handle's RefCount
is incremented as well.
* When closing a file, the file handle's RefCount is decremented
(and the file closed if the RefCount reaches zero), and the file's
parent device handle is also closed, recursively.
This has the effect of decrementing the parent device handle's
RefCount, and the device's own RefCount is decremented as well.
IMPORTANT NOTE: The usefulness of handle-level RefCount is still
under question, and might be (consistently) removed in the future.
- Fix opening a device (disk) in direct access, when this device is
already opened. Indeed, we previously allowed direct access only if
the device was opened as such for the very first time (its RefCount
= 0 originally); no filesystem mounting was attempted as well.
Then for any later open-operations on this device (while keeping an
already-opened handle to it), filesystem access was assumed.
Thus, this problem would show up in two ways:
* Either the device is first opened for direct access, this succeeded
and no filesystem was mounted. Then, for any other open-operations,
the filesystem was NOT mounted, and opening files on it would fail.
Direct accesses would succeed but would create an unnecessary second
file handle.
* Or, the device is first opened for file-access: a filesystem was
mounted and file opening would succeed. Any other file opening
operation would succeed as well (if the file exists). But, a direct
access open-operation would fail, because now any open-operations on
the device would be assumed to be a file opening.
This is now correctly fixed. If direct-open is requested, just do it.
If this is a file opening, we open the device, then try to mount a
filesystem on it (if not already done), then we try to open the file.
If file opening fails, derereference the device.
- Pass the file path to the filesystem-specific Open() functions without
truncating the leading path separator, if any. This has to be handled
by the filesystem routines themselves.
