* I don't have time for this bullshit. Of course the irony is that a Microsoft product (CodeQL)
hosted on a Microsoft platform (GitHub) hasn't been updated to work with the latest Microsoft
compiler (VS2022).
* Also removed the stuff CodeQL complains about and updated README badges.
* Having two separate Visual Studio solution files, while more convenient, was a major
pain in the ass and it also required us to update versioning in the .appxmanifest for
each commit.
* Also, this new AppStore build process enables us to use the GitHub Actions executables
to further foster the complete transparency of our build process.
* This is a follow up to 1c2884ceba where the error code returned by Windows 7 platforms
that don't have KB2533623 is expected to be ERROR_INVALID_PARAMETER rather than ERROR_PROC_NOT_FOUND.
* Also update the Windows 11 'Extended' installation mode translations.
* Per 2a3e82fa96, it looks like some Windows 7 system have trouble with
LoadLibraryEx() if they don't have KB2533623 installed (which fixes a MAJOR Windows
vulnerability. Some people sure want to leave their system open to hackers...).
* Work around this by adding a fallback to LoadLibrary() in GetLibraryHandle()
* Also switch to using GetLibraryHandle() in dos.c and using LoadLibrary() in sections
where we have the full path (since these calls are not vulnerable).
* Commit 9dc045a701 introduced a regression on account that we didn't set the
file pointer to 0 before clearing the disk.
* This leads to the MBR not being properly cleared, with the result that Windows may in turn
produce errors when trying to repartition the disk.
* Fix this by making sure we do invoke SetFilePointerEx() before calling WriteFileWithRetry().
* Also set rufus-next to 3.17
* Also fix a MinGW warning
* Remove BypassRAMCheck from Extended Windows 11 installation since the minimum
RAM requirements for Windows 11 are 4 GB and not 8 GB as pointed out in #1791.
* Display Windows edition code when we can't resolve it.
* VS2019 wants us to have PackageOptionalProjectsInIdeBuilds enabled? So be it.
* If 'Extended Windows 11 Installation' mode is selected, the system registry hive of
'sources\boot.wim' is patched to add the Setup\LabConfig registry keys that bypass
the TPM 2.0/Secure Boot/8GB+ RAM Windows 11 system requirements.
* Use sources/compatresources.dll, when available, to try to detect the Windows ISO version and build.
* Also report what facility we use for formatting.
* Since version 8.2, and rhinstaller/anaconda@a766101954,
Red Hat derivatives have changed their CD-ROM detection policy which leads to
the installation source not being found when writing the media in ISO mode.
* Replace 'inst.stage2' by 'inst.repo' in the kernel options.
* Closes#1777 (See also rhinstaller/anaconda#rhinstaller/anaconda#3529).
* Note that this reverts part of 9c8fa40995.
* Windows 11 appears to be a lot more proactive in locking system partitions (ESPs, MSRs)
than previous versions of Windows were, resulting in format or access errors.
* Try to work around these by disabling exclusive drive locking as needed.
* Also use build number to detect Windows Server 2019 and Windows 11
since Microsoft are COMPLETE ASSES about their version reporting.
* Also fix a compilation warning.
* In replace_in_token_data() when looking for lines starting with a specific
token but finding lines containing a larger version of the token (e.g. looking
for 'linux' but finding 'linux16') we would forget to output the non matching
line as we rejected it.
* This produced issues such as the one described at:
https://ubuntuforums.org/showthread.php?t=2465291&page=10&p=14052629#post14052629
* Fix this by ensuring that we always output the lines that we reject.
* write_sector() should really only be used when writing single sectors as it
is way to slow for anything else => Switch to using WriteFileWithRetry().
* Also revert an unwarranted change from f0047986e7.
* ...that didn't get the memo about using UPPERCASE 11-chars max ISO labels.
* There's a reason why Arch labels its ISOs 'ARCH_YYYYMM', people!
* Anyway, EndeavourOS should now work in ISO mode when booted from UEFI.
* In their great wisdom, the openSUSE maintainers added a 'set linux=linux'
line to their grub.cfg, which means that their kernel option token is no
longer 'linux' but '$linux'... and we have to add a workaround for that.
