* Use of '*.*' as pattern in file save dialog could lead to assert and crash, so
we now try to derive the type of image to be saved from the file extension. We
also did not properly handle user cancellation in the file save dialog.
* Also update iso9660/iso9660_fs.c to latest proposal of El Torito image handling.
* Also add a couple asserts in the hash table functions so that, if these ever get
triggered we will pick them from Windows Store reports, and clean up code.
* Per linuxmint/linuxmint#622 some ISOs may have a /EFI/boot/bootx64.efi that
is a symbolic to a nonexisting file.
* This is originally due to a Debian bug that was fixed in:
5bff71fea2
* Work around this by trying to extract a working bootx64.efi from the El-Torito image.
* Also improve DumpFatDir() to not replace already existing files.
* Also update copyright year and improve uprintf error handling
* Also bump GitHub Actions dependencies. Note that we do NOT want to update to
upload-artifact v4 because it BREAKS the creation of artifacts from matrix.
See: https://github.com/actions/upload-artifact#v4---whats-new
* Closes#2382
* Closes#2383
* Mint have decided to make their installation rely on a working /live/ ➔ /casper/ symlink for LMDE
thereby breaking the promise of File System Transposition that all Debian derivatives should have.
* Because of this, trying to use FAT32 with LMDE will fail, as reported in linuxmint/live-installer#152.
* Therefore, now that we can replicate symlinks on NTFS, we add an exception to always enforce the use
of NTFS for LMDE.
* For some weird reason appending the base directory to the root syslinux.cfg
we create does not appear to work with Slax. So we now always patch ldlinux.sys
to include the base directory.
* Also add an exception to move the /slax/boot/EFI directory to /EFI.
* It should be noted that, as of slax-64bit-slackware-15.0.3.iso, the Slax UEFI
Syslinux bootloaders appear to be broken (since creating a media without using
Rufus at all per the Slax documentation does *not* produce a USB drive that was
bootable in UEFI mode on 2 of the machines I tried).
* Also clean up some iso.c code and fix some unreachable code in ntfssect.c.
* Closes#2336.
* Closes#2338.
* Removes the annoyance of having to wait for the process search to complete before media creation can start.
* Also update the "Process Hacker" references to its new "System Informer" name.
* Duplicated symlinked Rock Ridge files were not counted into the total size needed
to process the image and as a result, progress could go over 100% when extracting
data (e.g. debian-live-12.1.0-amd64-lxqt.iso).
* Fix this by adding the duplicated files twice in the total block size.
* '.wic' are DD images used by the Yocto project.
* Why Yocto chose to use their own extension instead of using the de-facto '.img' is beyond me but hey...
* Also update GitHub Actions dependencies to latest.
* Closes#2319.
* Due to a typo in vhd.c where the second safe_stricmp() should be against ".vhd" and not ".vhdx" again.
* Also enable the ignore boot marker bypass for VHD/VHDX/FFU and don't misreport those images as
"compressed disk images".
* Closes#2309.
* This is placed behind an expert wall (Ctrl-Alt-E) on account that:
- If you happen to boot a Windows To Go drive in S Mode on a computer, it may set any
existing Windows installation there to S Mode as well, *even if their disk is offline!*
- It can be *exceedingly* tricky to get out of S Mode, as the SkuPolicyRequired registry
trick alone may not be enough (i.e. You can have very much a Windows install in S Mode
*without* SkuPolicyRequired being set anywhere).
* Also set version to rufus-next and fix a ChangeLog typo.
* Per https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Directory_entry it
is possible to have a FAT directory entry with a 'EFI' volume label alongside with
a 'EFI' subdirectory.
* If that happens, then the current Syslinux libfat_searchdir() code may treat the
'EFI' volume label as an empty subdirectory and say that there are no bootloaders,
even if the 'EFI\Boot\Boot###.efi' binaries really do exist.
* Fix this by filtering out entries with the 'volume label' attribute (0x08).
* For good measure, also filter out entries with the 'device' attribute (0x40), as
it is technically possible to create a 'EFI' device leading to the same issue.
* Closes#2288.
* Closes#2289.
* As opposed to what we originally asserted, Microsoft did enact a blanket revocation
in SkuSiPolicy.p7b for all post 1703 up to 2305 Windows UEFI bootloaders.
* As a result, unconditionally copying SkuSiPolicy.p7b will result in media as recent
as Windows 11 22H2 (v1) being flagged as revoked, which we don't want to enforce as
long as Microsoft themselves haven't entered the enforcing phase of their Black
Lotus mitigation (currently planned for early 2024).
* Because of this, while we add some revocation detection for post 1703 bootloaders,
we set it to only go as far as 20H1 for now, which means that all post 20H1 Windows
10 media and all Windows 11 media will not yet be flagged by Rufus as revoked and
will still boot in a Secure Boot environment due to lack of an SkuSiPolicy.p7b.
* Ultimately, per #2244 we may look for a BOOTMGRSECURITYVERSIONNUMBER resource to
blanket revoke all post 1703 - pre 2305 Windows UEFI bootloaders.
* Also remove the now unused comdlg32 library from the linker.
* SymLoadModuleEx() on the DLL fails (with ERROR_SUCCESS, sic) on ARM64, so we have to resort
to loading the DLL in memory and look for the "RSDS" section to access the GUID and Age.
* Except that, once you sort that, you end up with SymEnumSymbols() producing two separate
addresses for each symbol, on account that the Windows 11 ARM64 DLLs are actually an
unholy union of X64 and ARM64 *in the same binary*, under an abomination that Microsoft
calls ARM64X (See https://learn.microsoft.com/en-us/windows/arm/arm64x-pe for details).
* And, of course, Microsoft did not provide any means during PDB enumeration to tell which
address is for which arch. Especially, the bloody pSymInfo->TypeIndex, that they could
easily have used for this, is utterly pointless as it remains set to 0...
* This means that, even after all this effort, we're still nowhere close to have a solution
that can make DLL address resolution work on Windows 11 ARM64.
* With ISO-9660 being case sensitive, we could end up in situations where trying to extract
'/efi/boot/bootx64.efi' for revocation validation would fail if the file on the image was
stored as '/EFI/boot/bootx64.efi' (e.g. Debian 12).
* Fox this by storing the exact UEFI bootloader path we detected during ISO scan, and using
this path for file extraction.
* Also add a Cancel choice to the revocation dialog and harmonize whitespaces.
* Having NTFS partitions properly aligned to the cluster size can drastically
improve the speed of capturing a disk to an FFU image, as, when the size
is aligned, the FFU capture uses the actual NTFS allocation map to only read
and capture the clusters that are actually in use, whereas, if no aligned,
FFU capture falls back to a sector by sector copy that is both much slower
and also includes unwanted leftover garbage.
* Also only enable FFU when we detect FFUProvider.dll as a system library.
* Full Flash Update (FFU) image support was added to dism with Windows 10 1709
and is an alternate way to save a virtual hard disk for restoration.
* While more modern than VHD/VHDX, FFU creation only works for drives with file
systems that Windows natively recognizes (FAT, NTFS) and that look like Windows
installation media, so you can forget about FFU'ing a Linux disk.
* The other *intentional* drawback that Microsoft added is that they don't want
anybody but themselves being able to create and restore FFU images, so, even
as they have nice FfuApplyImage()/FfuCaptureImage() calls in FfuProvider.dll
they have decided not to make these public.
* This means that, since we don't have time to spend on figuring and direct
hooking internal DLL calls for x86_32, x86_64, ARM and ARM64 (and worrying
that Microsoft may ever so slightly change their DLL between revs to break
our hooks), we just call on dism.exe behind the scenes to create the FFU.
* MinGW32's delay loading functionality is not yet up to par with MSVC's and especially, for
some libraries (wininet, virtdisk) attempting to delay load them simply crashes the runtime.
* This results in the MinGW32 version of the app crashing when selecting a Windows ISO, as we
will then try to mount the ISO using virtdisk to poke the build version. Note that this crash
does not happen with the MinGW64 version or with MSVC.
* Closes#2272.
* Also fix a Coverity warning in SaveImageThread() and improve the VHD saving code.
* Now that we don't have to deal with Windows 7, we can use CreateVirtualDisk() to
automatically dump a physical disk to VHD/VHDX, so do just that
* Also move the relevant VHD/ISO imaging call to the appropriate source.
