* 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.
* Of course, since Grub4DOS's grldr.mbr hasn't changed from previous releases
there's not much to update there, but then again, people like version bumps.
* InternetGetConnectedState() is next to useless and doesn't provide
coherent outcome on the ARM64 platform I'm testing with. This results
in Rufus declaring that Internet is unavailable on platforms that do
have actual Internet connectivity.
* Swicth to using INetworkListManager::GetConnectivity(), which actually
reports a dependable result.
* Closes#1691
* Also remove the mutex for uprintf(), which may produce thread lockout
and remove an unwanted double GetSignatureName() call on startup.
* Looks like executables installed from the Windows Store launch with a "/InvokerPRAID"
added parameter, which of course BREAKS apps that have a defined set of parameters
and don't except that Microsoft would gingerly add random unwanted stuff there...
* The provision of this extra parameter also appears to be tied to using one of:
- <TargetDeviceFamily Name="Windows.Universal" ...>
- <uap:SplashScreen ...>
- <Application EntryPoint="$targetentrypoint$" ...>
in the appxmanifest.
* This resulted in our argument processing loop to cause early exit on account that an
unexpected option was provided.
* Fix this by adding an explicit check for /InvokerPRAID and not exiting on unhandled
params and removing or altering the 3 appxmanifest options listed above.
* Also set an explicit Windows.FullTrustApplication and remove splash screen.
* Also update _pre-commit.sh to update appstore build number automatically.
* Also remove splash screen images, add store listing CSV and toggle App builds to manual.
* Closes#1690
Yes!!! We are finally *much* faster than 7-zip for SHA-256, even though
we are also computing MD5 and SHA-1 in parallel. Here are some averaged
comparative results, against the 5.71 GB Win10_20H2_EnglishInternational_x64.iso
(SHA-256 = 08535b6dd0a4311f562e301c3c344b4aefd2e69a82168426b9971d6f8cab35e1):
* Windows' PowerShell Get-FileHash: 48s
* 7-zip's SHA-256 : 31s
* Rufus (64-bit release version) : 23s
* Due to the partition gymnastic that is required by the hack that is ISOHybrid,
some ISOHybrid images that are written in DD mode, such as Ubuntu 20.10, may
result in Windows somehow "losing" the target disk from some of its listings.
* This "removal" can be seen for instance if you have diskpart already open and
issue 'list disk' after Rufus 3.13 completed its image writing.
* In the worst case scenario, Windows may flat out refuse to access the disk at
the sector level be it in diskpart or disk manager, which forces ones to clear
the partition tables on Linux or some other OS to be able to "recover" the disk.
* This appears to be mostly due to Windows VDS cache (which Microsoft assures
should be able to do a proper job of refreshing itself on its own, in the same
stride as they also feel the need to introduce IVdsService::Refresh whose sole
purpose appears to work around a limitation that Microsoft knows exists) not
being in sync with the actual disk layout.
* So we now add calls to VDS layout refresh where needed, to work around the issue.
* Also fix an ext2fs Coverity warning.
* For blank disks, GetVdsDiskInterface() may return success with a NULL pAdvancedDisk.
* Also silence the annoying "Failed to read label" error on ERROR_UNRECOGNIZED_VOLUME.
* When writing images such as tails, that contain a large ESP, Windows forcibly
removes the media while we are writing it, unless we lock the logical drive.
* Also fix a Bled Coverity warning.
* Remove early locking of logical volume (no longer necessary due to previous commits).
* Relax exclusive locking of physical drive when an ESP is created.
* This should help with #1637 and #1640
* Also add an extra check for sector size in WriteDrive()
* Factorize drive letter removal into a RemoveDriveLetters() call.
* Improve MountVolume() and RemountVolume() calls.
* Also bump Rufus version to 3.13
* Make sure that instantiated objects are released.
* Factorize the instantiating of disk interfaces.
* Allow the provision of an offset to delete a single partition.
* Add a ListVdsVolumes() call (which is pointless since Microsoft *CRIPPLED* its VDS implementation).
* SetAutoMount()/GetAutoMount() should check for INVALID_HANDLE_VALUE and not NULL.
Also we don't actually need to open MOUNTMGR_DOS_DEVICE_NAME rw to issue an IOCTL.
* ToggleEsp() failed to exit properly when an ESP offset was specified.
* Introduce PI_MAX to explicitly set the size of the partition_information table.
* write_sectors() has write retry, so there's no need to perform one on top of it.
* When we exit FormatThread(), GetLogicalName() should attempt to look for the the
main partition and be silent.
* Make sure that if we skip a deep directory during scan, we count at
least one block of data.
* Also produce a note about deep directory long scan times and improve
the formatting of some messages.
* Ubuntu switched to using GRUB for BIOS, so our update_md5sum() code was not being called.
* Move update_md5sum() to being called unconditionally to fix this.
* Closes#1616 (again...)
* GRUB have cherry-picked patches from the "BootHole" vulnerability fix at
https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html and
have applied them to their 2.04 GRUB loader.
* This results in breakage with "error: symbol 'grub_calloc' not found" when
using the release GRUB 2.04 version of core.img.
* Therefore, we too cherry-picked some patches to apply on top of GRUB 2.04
release to make our core.img compatible with Ubuntu 20.10.
* Closes#1616
* Also increase the maximum write stride for ms-sys to 64 KB (required to
write the GRUB 2.05 bootloader which is larger than 32 KB) and update hash DB.
* The presence of a > 4 GB file forces the use of NTFS which is incompatible with
SysLinux 4.x or earlier. As such, if an image uses SysLinux only, there's no
point in enabling MBR as SysLinux won't boot.
* Required for ISOs such as securityonion-2.0.1-rc1.iso.
* Commit 77d319267f broke lookup of ISO filenames since iso9660_open()
enabled the Rock Ridge extensions by default, despite using ISO_EXTENSION_NONE
for the internal call, and we addressed a FIXME related to this.
* This resulted in Rufus not being able to lookup 'boot/grub/i386-pc/normal.mod' to parse GRUB's
version, since without Rock Ridge, 'i386-pc/' is unable to match the ISO-9660 'I386_PC/' dir.
* Closes#1573 and addresses part of #1616.
* Also fix a MinGW compilation warning.
* These bootloaders will require LFN support. Since we don't expect that
many people to create bootable media for RISC-V derived from bootloaders
contained in a 'efi.img`, we simply ignore these for now.
* Don't use hDrive handle for longer than necessary
* Move all the popcount() function calls into missing.h
* Ensure that the thread_affinity[] array is properly sized
* Improve timeouts for conflicting process search
* A user is reporting that, on one of their platforms, Rufus is writing to the wrong target during the file-copy
phase and using their existing Y: local drive instead of the drive associated to the USB, despite the fact
that Rufus is passing the right volume name to GetVolumePathNamesForVolumeName().
* Here's the PowerShell wmic output, confirming that the volume GUID obtained by Rufus is the right one:
DriveLetter : Y:
DeviceId : \\?\Volume{000349b1-17d0-69f6-c13f-f31162930600}\
Capacity : 118540464128
FileSystem : NTFS
Label : Y-DISK
DriveLetter : H:
DeviceId : \\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\
Capacity : 15791824896
FileSystem : FAT32
Label : ADATA16GB
* And here's the Rufus log demonstrating that GetVolumePathNamesForVolumeName() is returning the *WRONG* letter:
Found volume \\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\
\\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\ is already mounted as Y: instead of H: - Will now use this target instead...
* The last line shows, without the shadow of a doubt, that we did feed "\\?\Volume{b150ff4a-d62b-11ea-86e3-f49634660e54}\" to
GetVolumePathNamesForVolumeName() and that this API call was successful (returned a non zero size) but ultimately returned
the wrong letter (Y: instead of H:)...
* Therefore, Windows is BUGGY and the use of GetVolumePathNamesForVolumeName() must be avoided.
* ISOs with tons of Rock Ridge deep directory entries (such as OPNsense)
can be very slow to scan due to the nature of deep directory parsing,
which requires processing the whole ISO9660 fs, for each deep directory
file, in order to find the relevant LSN entry.
* Since we don't expect much of the content we care about to reside in a
deep directory entry, we amend the code to cut short the scan of any
directory that contains such elements.
* Note that this only applies for ISO scan and it does nothing to speed
up the ISO extraction process.
* Related to issue #1575
* Closes#1467
* Also ensure that previous element is set when repositioning a
control to preserve tabbing order
* Also fix x64 version being able to download x86 BETA
* This is mostly aimed at Debian 11 netinst on the Raspberry Pi 4
* Only available for regular UEFI ISOs if GPT and FAT are selected (no MBR ESPs).
* Also fix a MinGW warning in GetUnusedDriveLetter()
* Now use version 1.6 of the EfiFs drivers that enables firmwares that
don't provide EFI_DEVICE_PATH_TO_TEXT_PROTOCOL to mount NTFS partitions
regardless.
* Also use the latest version of UEFI:NTFS that displays additional info
about the system.
* Closes#1213.
* Also update version to Rufus-next.
* ASLR is enabled by default for Visual Studio builds but that isn't the case
for MinGW builds. Fix that and also add -Wformat-security while we're at it.
* Closes#1518
* Also ensure that we'll never write protective MBR message for non-bootable
GPT drives, even as we are not calling WriteSBR() for those anyway.
* Also fix SBR message not being written for bootable images
* Also add an extra partition refresh after deleting partitions to try
to further force Windows take its stinking paws off our drive.
* Fix RTL location of "ISO" in the "Copying ISO files" translation for Arabic and Persian
* Fix whitespace/message ending issues for various translations
* Sync all .po's with .loc to avoid another German progress update is missing issue
* We distractedly chose to populate the message from our protective MBR
for GPT/UEFI-only boot media into the 4KB that directly followed the
MBR, which of course is space that is being used by the primary GPT.
* This resulted on systems having to fall back to using the secondary
GPT, which not all appear to be designed to do.
* Alter the code to ensure the protective message is written at LBA 34,
after the primary GPT.
* Closes#1507
* If a converted label contains mostly underscore, the proposed
label is used for FAT32 instead. However this label still has
the KB/MB/GB symbols localized so it may be invalid.
* Ensure that we use a non-localized version of the size when
using such a label.
* Closes#1506.
* Also fix a VS2019 static analysis warning in net.c.
* The upcoming Ubuntu 20.04 comes with MD5 validation turned on by default.
* When creating persistent boot media, we may update some of the validated files
to add persistence, update the search labels, etc.
* Make sure that the files we modify get their MD5 updated where needed.
* Also add 'loopback.cfg' to the list of config files we can add persistence to.
* Part of #1499
* Among other nefarious things, ubuntu 20.04 added a $casper_flavour suffix
to their grub.cfg /casper/vmlinuz kernel option, so we can no longer rely
on 'persistent' being inserted in a proper location.
* Switch to latching on file=/cdrom/preseed and hope that it will work for
all of Ubuntu & derivatives.
* Part of #1499.
* Commit 4c5adf092e moved us away from using CreateFile()
when extracting a file on the target media, and as such the error code returned when
failing to create an 'autorun.inf' due to a security solution has shifted.
* Make sure we handle the new error and don't bail out on 'autorun.inf' creation.
* Also update the actual name of the RtlDosPathNameToNtPathNameXXX function we use.
* Closes#1496
* Recent versions of Windows can set the deafult locale to codepage 65001 (UTF-8).
* This produces an assert due to a missing entry in cp_hr_list[], so fix that.
* However, this fix alone is not enough, as a GetOEMCP() that returns 65001 means
that any systems set to UTF-8 will fall back to codepage 437 for DOS, which is
definitely not what we want => Add an extra call to determine the actual OEM
codepage when UTF-8 is detected.
* Closes#1468
* Commit [e522ef6c55] (PR #1426) regressed the '%s'
progress messages back to '%0.1f%%' which results in the percentage remaining at
zero when the UI is in German.
* Surround macro params to ensure expected results
* Fix copy-paste errors
* Fix a potential buffer overflow in SetSectionHeaders()
* Add const modifier where relevant
* Use GetWindowLongPtr() everywhere
* Use proper sprintf format for unsigned int
* Use %s for printf-like funcs (https://www.viva64.com/en/w/v618/print/)
* Closes#1464
* Status code assignation was removed when the original code
was altered to use pfNtFsControlFile(). Fix that and also
make the code more similar to other calls.
* Closes#1459
* msg.S now reads an ASCII message (with escaped colour sequences)
from the following blocks, which is both more flexible and allows
for more content to be displayed.
* Also adds Bochs testing to the MBR build facility
* Hopefully using DICS_FLAG_CONFIGSPECIFIC instead of DICS_FLAG_GLOBAL is all that was needed
to get device disabling/re-enabling work without creating zombie devices, because we sure
need to force Windows' hand when it comes to detecting logical volumes...
* Implement CreatePreallocatedFile() which uses NtCreateFile() to create files with preallocated sizes.
This is used during ISO extraction to improve performance.
* Remove now-unused preallocate_filesize which was called after CreateFileU().
* Closes#1445
* ClearMBRGPT() attempts to write WRITE_RETRIES times, even if all those times succeed.
* Instead, skip the remaining retries on success.
* Also improve code readability.
* Closes#1454
* So, as it happens, when assigning the product of two 32-bit variables into a 64-bit one,
compilers default to being *DUMB* and, against all reasonable expectations, do not perform
that multiplication as a 64-bit operation (even when the code is compiled as x64). Wow,
that's really great decision making by compiler designers if I ever saw some... Whoever
decided that C developers would much rather want truncation and 32-bit overflows, instead
of the expected *LOGICAL* behaviour of conducting arithmetic operations as 64-bit when the
result will be assigned to a 64-bit variable, need to be condemned to a lifetime of trying
to help elderly folks trying to conduct simple computing tasks as a punishment...
Anyhoo, nt_write_blk()'s offset.QuadPart = block * channel->block_size + nt_data->offset
was overflowing 32-bit as soon as block * channel->block_size went over the 4 GB mark,
with the disastrous results one can expect. Considering that this is code we practically
lifted verbatim from e2fsprogs, I guess e2fsprogs' NT I/O manager was never properly
tested with anything larger than a 4 GB. Awesome!
* We fix the above by doing what unix_io.c does and setting the 32-bit read/write_blk()
calls to be wrappers around their 64-bit counterpart (since, once you deal with a 64-bit
block variable, the computation is conducted as 64-bit).
* Also remove a bunch of stuff we don't need from config.h
* Closes#1396
* Fix use of EXT2_BLOCK_SIZE() instead of EXT2_INODE_SIZE() during inode
initialization, that made us zero way many more blocks than was needed.
* Also disable sparse_super feature and improve block setup.
* Also explicitly use IS_POWER_OF_2 macro where required.
* Most distros (Debian, Ubuntu) have moved to using Sylinus 6.04 even
as it has NOT officially been released, so we want our fallback to
work against this too.
* pre1 since the Syslinux folks advise against using pre2 or later...
* Closes#1444
* Only applies for blank UEFI:NTFS drives for now. UEFI:NTFS Windows drives are
still set to use NTFS only (since Windows 7 doesn't support UEFI exFAT boot).
* While compressed EFI bootloaders are not an issue for UEFI:NTFS, some UEFI firmwares
embed an NTFS driver that doesn't support NTFS compression.
To address that, also uncompress the EFI bootloaders on NTFS.
* Closes#1424
Yet another link in the long chain of Microsoft making it UNFATHOMABLY DIFFICULT
to figure out what version of Windows an application is actually running on...
* When using compressed NTFS, having a compressed bootmgr prevents BIOS boot, so we
now call `compress -u` where needed to leave the relevant bootmgr files uncompressed.
* Closes#1381
* Also fix a minor warning in ext2fs
* Windows platforms prior to Windows 10 1703 cannot access any logical partition besides the
first one (we don't even get a volume for those).
* This fix enables the use of physical + offset for ext# formatting to work around this,
which is file since we don't actually need to mount the partition.
* Also fix ext2fs_open2() not handling normalized versions of Windows drive paths ("\\?\...")
* Also fix an issue where we would make the drive letter unavailable after formatting a
standalone partition to ext#.
* Also ensure that we return an error if the drive we attempt to locate a partition on
through an offset does not match the currently selected one.
* Also remove some unused calls in drive.c.
* Closes#1374
* While we need to detect that 'txt.cfg' is a Syslinux config file, so that
we can alter it for persistence, it should never be used as a main config
file, such as the one we link to when we create /syslinux.cfg.
* Closes#1375
* Because we install our own ldlinux.sys, we must ensure that if the ISO contains
an ldlinux.sys in the root directory, this file is not copied over. However, our
comparison for the 'ldlinux.sys' string was case sensitive which means that some
ISOs such as R-Drive Image boot ISO, that use 'LDLINUX.SYS' were trying write over
our file, resulting in a file extraction failure.
* This patch ensures that the string comparison for 'ldlinux.sys' is case insensitive.
* Also add 512px sized icon (upscaled using waifu2x)
* Make sure they are always unchecked for pure DD images
* Make sure Quick Format is checked and disabled for ReFS or Large FAT32
* Also make sure Fixes for old BIOSes is disabled for pure DD images
* Remove unused iso_op_in_progress and use a single op_in_progress that gets
set when we disable the controls.
* Also fix an issue where Ctrl-L was being processed as Alt-L due yet another
completely backwards Windows behaviour where the message that is meant to
indicating whether Alt is pressed is also sometimes used to indicate that
another key is being pressed if the dialog doesn't have keyboard focus...
* You can use <Alt> to switch modes during an operation that supports it (e.g. Checksum
computation, DD image writing or zeroing, save to VHD, download, etc.
* IMPORTANT: This is *NOT* available for all operations. Especially, if you were hoping
to get transfer speed or ETA during ISO or WIM extraction, you *WILL* be disappointed.
* Also harmonize the code in checksum.c
* This is to avoid Microsoft's appalling refresh of the partition layout,
which can result in partitions not being assigned a volume GUID.
* Mostly reverts a change that was applied in 1c39a80d72.
* Also add some more enum output and bail if we can't get a logical drive.
* Closes#1351
* Also fix another round of Coverity trigger-happy warnings (Seriously, those FALSE
POSITIVES about fwprintf can £$%^&* off — fix your frigging detection, Synopsys!)
* Only UEFI boot for now (GRUB) & requires a post 2019.07.26 ISO for Ubuntu.
* This adds the relevant persistence/persistent kernel option to the conf file, sets the
expected volume label and creates a /persistence.conf file where needed.
* Also improve token parsing by ensuring a token is followed by at least one white space.
* Only happens on Win7 due to MinGW not automatically initializing variables to zero on that platform.
* Root of the problem was that GetWindowTextU() did not properly handle empty text controls, due to
GetWindowTextW() returning 0 on empty strings. As a result, the UTF-8 label was not properly set to
the empty string, but kept whatever data it contained, which is garbage on Windows 7 and resulted in
an invalid label (even after sanitizing, since we don't sanitize low-level ASCII characters).
* Closes#1352
* Regression was introduced with 3c1ef23ff3 and 2ff6da49f0.
* Because of it extended label and icon, fixes for old BIOSes and Rufus MBR were not applied.
* Closes#1348
* Sorry Azerbaijani speaking people, but this was only added out of
good will and, with no new translator volunteering, this out-of-date
translation was holding us back.
fs.c:61:25: warning: taking address of packed member of 'struct fat_boot_sector' may result in an unaligned pointer value [-Waddress-of-packed-member]
61 | sectorsize = get_16(§buf->bsBytesPerSec);
| ^~~~~~~~~~~~~~~~~~~~~~~
* Only enabled when Advanced format options are shown
* Also enable reading of extfs volume label
* Also improve GRUB lookup fallback
* Also fix possible truncation when sanitizing labels
* Also write a zeroed MBR when non-bootable is selected
* Add VDS formatting support (through an Alt-V cheat mode)
* Add partition index support
* Improve(?) Windows To Go support by following Microsoft recommended partition order
* Code refactoring & cleanup
* Add display of persistence controls on relevant images
* Add progress on ext3 formatting and improve error reporting
* Also improve MountVolume() and fix some Coverity warnings
* NtWow64QueryInformationProcess64() fails because sizeof(PVOID64) happens to be 4 instead of 8 in MinGW32 (WTF?!?) and
therefore sizeof(pbi) is set to 44 instead of 48, resulting in NTSTATUS code 0xC0000004: STATUS_INFO_LENGTH_MISMATCH...
=> Use an ULONGLONG instead and don't rely on MinGW32's improper definitions.
* Also fix an issue whereas, when we find multiple conflicting processes, the first one's path is duplicated to all others...
* Also disable Launch button while we do so
* Also add new <Ctrl>-<Alt>-<Y> cheat mode
* Also terminate update thread before exiting if running
* Also set version to rufus-next
* Since we have compression available through Bled we might as well use it
* Also validate that the download URL comes from https://github.com/pbatard/Fido
* Also prevent the check for update from running while we are downloading ISOs
* Also fix an issue where Rufus doesn't report an error if 'fmifs.dll' can't be found (#1284)
* Also improve GitHub issue template to mention that Ctrl-L can also be used to access the log
* This should help Windows users who create a GPT/UEFI drive and try to use it in BIOS/Legacy
* Also make sure that we take into account the split space for both "SELECT" and "DOWNLOAD"
* What would be nicer was if half these Coverity issues weren't false positives...
* Also update Readme and fix progress bar colour not being reset after error
* FS selection might default to NTFS instead of FAT32 after having selected a Linux ISO if
no drive was plugged in when the ISO was selected and then a drive was plugged using NTFS.
* Also display Fido's exist code
* Closes#1255
* Center dialog on open
* Close dialog on main application exit
* Display ISO short name & size on status bar during download
* Display ISO download progress on taskbar
* Also fix improper detection of EAGET Mass Storage USB Device as HDD
* This is accomplished through Fido (https://github.com/pbatard/Fido), a *SIGNED*
PowerShell script, that is downloaded from GitHub and that resides in memory for
the duration of a session.
* The reason we use a downloaded PS script, rather than an embedded on, is because:
- Microsoft have regularly been changing the deal with regards to how retail ISOs
can be downloaded, and not for the better, so we can't simply embed a static
means of downloading ISOs and expect that to work forever.
- By using an external script, we can immediately respond to whatever new means of
*ANNOYING* their legitimate users Microsoft will come up with next, as well as
make sure that, the minute a new retail version of Windows becomes available, it
also becomes available for download in Rufus.
* Note that if you are concerned about downloading a remote PS script that is being
run at the same level as an elevated application, you should understand that:
- Only scripts downloaded from GitHub, from an account that is protected with 2FA,
are allowed to run (i.e. someone would first have to steal a *physical* 2FA key
to be in a position to upload a malicious script).
- On top of this, only scripts that are signed with a separate private key (RSA +
AES-256), that is itself also protected with a strong unique password which only
a single person knows (and must manually enter each time they want to make a new
version of the script available for download), are allowed to run.
The above means that there's about as much chance for someone to manage to upload
a malicious script on the GitHub servers, that Rufus would allow to run, as there
is for someone to upload a malicious version of Rufus itself.
Still, if you are paranoid and have concerns that, even as you can validate from
its source that Rufus does not attempt to execute any remote script unless a user
actively selected and clicked the DOWNLOAD button, you can also completely disable
the remote script download feature, if you just set the update check to disabled
(which, by the way, Rufus *EXPLICITLY* asks you to choose whether you want to
enable or not, the very first time you run the application).
* Also remove _unlinkU() which duplicates what DeleteFileU() already does.
* Closes#1268
* Issue was introduced in 521034da99 and has
to do with VS2017's handling of static strings in RELEASE mode.
Fix is to use a static char array instead.
* Also fix MinGw build warnings and increase process search timeout
* Relying on system MUIs was too brittle and provides us with no guarantee
that the translated messages we need will actually be there.
* Also fix space before question mark in French translation.
* With no thanks whatsoever to Microsoft for *NOT* documenting that you need
to pass flag 0x2000000 to WIMCreateFile() if you want to avoid an open error.
One has to wonder if Microsoft isn't deliberately adding *BULLSHIT FLAGS*
that only they know of, to hinder competing third-party tools...
* Also revert a472e96e87 as this is creating
unwanted detection issues as per #1239. We'll try to devise a better way
to avoid intempestive refreshes later on.
* efi.img was not always being properly process (e.g. proxmox-ve_5.2-1.iso)
* Note that this doesn't mean that the ISO will properly boot, just that we will
now properly detect and install the EFI bootloaders that reside within the .img
* Instead of x86_32 and x86_64.
* This should aid with our appxbundle creation and if Microsoft want to
be wholly incorrect in their arch designations, who am I to judge?...
* FAT32 would become available and selected as default FS when
selecting a Windows ISO with a >4GB file and then clicking
"Show advanced drive properties".
Tiryoh
Костянтин Сергійович
Pete Batard
Suttirak Mattayawerakiat
Jakub Zieciak
MaKK
Martin Kubánik
Riku Brander
Dinis Medeiros
Chocobo1
Jiawei Wang
Thilo Langbein
Miloš
Itiel
Aldis Tutins
Roberto Boriotti
Thomas De Rocker
Uk-Jin Jang
Arif Budiman
Sopor
Mehmetali Kuran
Tiago Filipe Silva
Fardin
İlhami Tuğral
dmex
Derek Foreman
נועם סרוסי
Tsarevich Dmitry
crazyZhang
Mattiwatti
David Stumph
User
Mr-Update
Joseph mendoza
ichikuma7
TotalCaesar659
ImgBotApp
LaszloEr
fufunelaf
Mohamad Ikhwan bin Kori
alex f
Neoheresy
marcellogianola
Sasa Vujanic
Кристиан Дочев
Gintaras Venslovas
anni deer
Zia Azimi
Matej Horvat
Viszokai György
Richard Kahl
Cao Bach
Tiago Rinaldi
Gîrlea Alexandru
Feras Mohammed
Кирилл Иванов
Radosław Serba
Charles Stevens
SIPPAPAS WANGSRI
Nikos Margaritis