* 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.
* 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
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...
* 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.
* Some Thai UTF-8 notification messages went over the buffer size limit we used for vsnprintf()
* Also, revert part of 645184f11e and use LRE+PDF marks instead:
Don't handle in the code what is better handled in the loc file.
* Rufus now checks for processes with handles opened on the drives/volumes before
starting the format operation and asks the user if they want to continue.
* This mimics Windows' behaviour when formatting drives, and actually uses the
same message as the one from shell32.dll.mui.
* Closes#773
* Fix memory leaks due to not releasing the heap
* Also speed up lookups by not reopening the same process twice in a row
* Also make the usb_debug variable global so we can use uuprintf everywhere
* Enable the use of GPT on REMOVABLE drives, if the host is Windows 10 CU
* Don't display the message about REMOVABLE boot, if the target is Windows 10 CU
* Tooltips can only be manipulated from the same thread as the one that created their parent
* Also increase the SetLGP() timeout as this seems to be problematic
* Closes#764
* Someone running Rufus in a VirtualBox environment, where their CPU
was also seeing 100% usage, reported getting the following message:
"SetLGP: Killing stuck thread!"
* Use the commonly used function names for SHA-256 (Sigma, etc.)
* Use the same xxx_write for all, and avoid unwarranted memcpy
* Remove the bitcount
* Use nested ROR() speedup
* Since Microsoft forces our hand, we hack away into our compiled RC
resources and change dialog attributes on the fly so that:
- we can switch between LTR & RTL
- change the font for Windows XP
* Note that the base RC font has been changed to "Segoe UI Symbols"
so that it looks the same in the editor (at least for English) but
can accommodate the length required for "MS Shell Dlg"
* This creates issue due to dism incompatibilities between Windows versions
and some users are puzzled why they don't see their internal disks.
* Also make the bcdboot call more robust by using the system one if the USB one fails
* Also fix small issues in RunCommand() and MountVolume()
* Our detection for a match in the hash table, during USB enumeration, always
pointed to the first hub when no match was found.
* Also, some USB mass storage devices (ASUS Turbo Mode devices, iPods) may
have an additional driver inserted, which we now try to handle by looking
up the grandparent.
* Thanks to NaoDarkness for helping investigate this
* Closes#513
