* 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.
* If users set the persistent size to max, we may run into a situation
where projected size (which is always a rough estimation) is too low.
* When persistence is in use, we increase the projected size by 10%, to
ensure that the above scenario cannot happen.
* Also work around potential issues with Windows APIs when the application
is launched from the root of a drive.
* While this is intended to solve the issue of saving GRUB/Syslinux files for the
App Store version, we apply this change globally, as it allows the user to move
the Rufus executable around while preserving access to existing downloads.
* Closes#1744
* This basically means that the script is validate *TWICE*, using two
completely independent signatures, before it is allowed to run, which
should add another mitigation layer against TOCTOU (which we already
friggin' mitigated against anyway) and other potential vectors of
attack.
* Also remove -DisableFirstRunCustomize option and the associated cookie
prompt monitoring, which the latest version of Fido no longer requires.
* Also update WDK version for signtool and flesh out PKI error messages.
* Trying to mount accessible partitions after writing an image may lead to the
creation of the infamous 'System Volume Information' folder on ESPs, which in
turn leads to checksum errors for Ubuntu's boot/grub/efi.img (that maps to the
Ubuntu ESP). So comment out that code.
* Also fix a missing CRLFs in the log after displaying write progress.
* Anaconda broke ISO compatibility, most likely with the following commit:
84529204fe
* However, Ret Hat, and its followers, have drunk the "DD only" kool aid, and
appear to be blissfully unaware of the very real drawbacks that enforcing a
"DD only" mode for ISOHybrid can actually place on distro users.
* Rather than spend another wasted effort trying get people, who appear to be
impervious to even remotely consider the idea that DD imaging can have flaws,
to look into the possibility that Red Hat might indeed have introduced a
regression, and given the downright hostility I have been subjected to from
trying to state this *very verifiable* fact, we'll just force DD mode for the
affected Red Hat and derivatives, whilst trusting that users will be smart
enough to compare their more limited installation experience against the ones
from other distros (such as Arch, Debian or Ubuntu, which, unlike Red Hat and
co., appear to fully understand that the whole ISOHybrid vs DD mode situation
is not all black and white), and see for themselves which distros do actually
place *their* interests first, rather than just the interests of the distro
maintainers...
* GRUB 2.0 maintainer think they're doing a fine job, even when there are
CRITICAL SECURITY FIXES that should warrant an immediate out of bound
release, and instead consider that waiting MONTHS or YEARS to release
anything is not a big deal at all.
* Ergo, distros, such as Ubuntu, start to pick whatever security patches
they see fit, since they can simply not RELY on the upstream project to
produce security releases in a timely manner. One such patch is:
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00012.html
* But since there is no new GRUB release per se, they still call their GRUB
version, onto which they applied patches that have come into existence
more than 2 years after the actual 2.04 release, "GRUB 2.04".
* Obviously, since GRUB 2.04 + literally hundreds of cherry picked patches
does deviate a lot from the last release, THINGS BREAK IN SPECTACULAR
FASHION, such as the recently released Ubuntu 21.04 failing to boot with
the error: grub_register_command_lockdown not found.
* Oh, and of course, regardless of all the above, if you ask anyone, they'll
tell you that there's nothing fundamentally wrong with the GRUB release
process (even if they should long have released 2.05, 2.05-1 and 2.05-2,
were their maintainer ready to acknowledge that delaying releases DOES
CREATES MAJOR ISSUES DOWSTREAM, as many people REPEATEDLY pointed to them
on the GRUB mailing list) or with the Ubuntu GRUB versioning process (that
really shouldn't be calling their version of GRUB "grub-2.04" but instead
something like "grub-2.04_ubuntu"). Oh no siree! Instead, the problem must
all be with Rufus and its maintainer, who should either spend their lives
pre-emptively figuring which breaking patch every other distro applied out
there, or limit media creation to DD mode, like any "sensible" person
would do, since DD mode is the ultimate panacea (Narrator: "It wasn't").
* So, once again, a massive thanks to all the people who have been involved
in the current GRUB 2.0 shit show, whose DIRECT result is to make end
users' lives miserable, while GRUB maintainers are hell bent on continuing
to pretend that everything's just peachy and are busy patting themselves
on the back on account that "Fedora recently dropped more than 100 of the
custom patches they had to apply to their GRUB fork" (sic). Nothing to see
here, it's just GRUB maintainer's Jedi business as usual. Besides, who the
hell cares about Windows users trying to transition to Linux in a friendly
manner anyway. I mean, as long as something doesn't affect existing Linux
users, it isn't a REAL problem, right?...
* Combined with the increase in buffer size from previous commits, this
should help us get close to a device's maximum write speed.
* Also add async write support to winio.h
* Also increase the buffer size for bad blocks check operations
* This is in preparation for async reads
* Also move open/close image operations to WriteDrive()
* Also increase DD buffer size to 32 MB to improve performance
* 2e1833e91e introduced issues with VDS since, despite what
Microsoft's documentation says, balancing CoInitialize with CoUninitialize
leads to VDS not properly relinquishing disk access.
