Start sync at wine-0.9.59
Start sync at wine commit 44ab294e0b6f285f1aab5fc8533a36e852be38fa
"setupapi: Move strdupW and strdupWtoA to the setupapi_private.h header."
by Alexandre Julliard, April 16, 2008
- Rename global hInstance to SETUPAPI_hInstance;
- Add ARRAY_SIZE in case it is not defined.
- Use the CRT oldnames library.
Remove the '-Dwcsnicmp=_wcsnicmp' and use the alias in the oldnames lib.
This will also fix wcslwr() usage in the next commits.
It contains the functionality of both the original bootcd (text-mode
1st-stage installer) and the livecd (that will include the 1st-stage
GUI installer later).
Our separate livecd ISOs become obsolete, and this completely removes
the need for the so-called "hybridcd" ISO.
Some details:
- The "hybridcd" build target is completely removed, since now the new
BootCD *is* basically what we used to call "hybridcd".
- The "livecd" build target is kept so far (to minimize the code changes),
but internally I start to refer to it as "LiveImage", and is reduced
to a minimum.
A minimal non-bootable "liveimg.iso" is built (but currently not
included within the BootCD). Its purpose will be to implement the
"ReactOS Live" functionality as a RAMDISK.
(We currently don't support other file formats apart from ISO and
flat disk for a RAMDISK).
The "ReactOS Live" (non-RAMDISK) is implemented by adding to the
BootCD file tree the files from the LiveImage.
These files add two root directories, "Profiles" and "reactos"
(which is the SystemRoot for the non-ramdisk LiveImage).
- The minimal text-mode ReactOS installation used for the 1st-stage
installer, including USETUP itself, and the executable for the
1st-stage GUI installer and the reactos.cab (installation source),
are moved to the root directory called "i386" (ideally, one directory
per architecture).
- The "bootcdregtest" target, i.e. the ISOs we feed our testbots with,
are left untouched, i.e. they are only constituted of the 1st-stage
text-mode installation, in the root directory named "reactos".
This commit is based upon an older SVN one:
svn path=/branches/setup_improvements/; revision=75273
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
