For some reason on Vista x64 0xdeadbeef isn't detected as an invalid handle and the whole thing crashes. INVALID_HANDLE_VALUE on the other hand is detected as an invalid handle, so use that.
Inspired by PoC test code by Aliaksandr in CORE-20535.
These tests are passing on Windows.
Co-authored-by: Aliaksandr Lebiadzevich <bsalex2025@gmail.com>
Somewhat help to read and interpret output, as the program is.
- Always output locale with 4 digits
- Always output PART items as s%02d:i%u
- Improve handling module/part errors
- Output string length too
as a hint that ''s are not actually empty.
CORE-18893
CORE-9069, CORE-13525, RELEASE-11
This new BootCD 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 only, but placed in a per-architecture root
directory ("i386", etc. as for the bootcd).
- Remove the ACPI APIC/SMP entries from bootcd.ini. They will be made
available via the Advanced Boot Options F8 menu in Debug builds, for
testing purposes only, in a subsequent commit.
This commit is based upon an older SVN one:
svn path=/branches/setup_improvements/; revision=75273
bootcdregtest installs ReactOS into "c:\Windows", therefore the old detection method of checking the "Windows" directory no longer works.
A previous change tried to fix this by adding "|| IsReactOS()", but that resolves to CConfiguration::IsReactOS(), which simply returns m_IsReactOS.
Use ::IsReactOS() instead to get our versionhelper function.
The code is using the conforming version, but _CRT_NON_CONFORMING_SWPRINTFS was defined, which caused it to crash. After removing the definition, MSVC throws a warning about an invalid argument for the format string, so fix that as well.
We will continue with this stuff when we can understand the root issues better
* Revert "[NTDLL_APITEST] Relicense implicit tls tests as MIT"
This reverts commit ec6bae2b31.
* Revert "[NTDLL:LDR] Add Implicit Thread Local Storage Support (#7594)"
This reverts commit 23043ce0b8.
Before Windows Vista, TLS directories were ignored by Ldr* in any module loaded after process creation, which meant that the TLS index in any delay-loaded module remained 0. This means that when running an application targeting Vista and above and its delay-load modules have TLS directories, the following events can happen:
One or more delay-load modules claim ThreadLocalStoragePointer idx 0, resulting in data corruption and possible buffer overflows as data intended for one of the immediate-load modules is overwritten.
None of the immediate-load modules has a TLS directory, so ThreadLocalStoragePointer is not initialized. This means that the program crashes when one of the delay-load modules attempts to access its TLS data.
Adding implicit TLS support improves support for NT 6.x/10 user-mode applications, including all contemporary major web browsers.
JIRA issue: CORE-19413
---------
Co-authored-by: Justin Miller <justin.miller@reactos.org>
