Jump to content











Photo
- - - - -

Rufus 3.0 has been released

rufus

  • Please log in to reply
42 replies to this topic

#26 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14715 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 September 2018 - 03:47 PM

Meh. Considering that they also mention that "make sure the device is plugged in but not mounted" I suspect this is another distro that decided to put all of its eggs into the ISOHybrid basket, without realizing the unintended consequences of it (such as Windows correcting the backup GPT record if the USB isn't the exact same size as the image drive, or any checksum validation being thrown off if you have an ESP on that drive).

 

Or maybe they just don't know that Rufus has a DD mode that (AFAIK) should work as well as any other DD application you'll find on Windows...

 

At any rate, I don't have much of an issue with distro makers pushing for whatever tool they think is most suited for the job of creating bootable media, even if they advertise for something else than Rufus to be used.

Yep :), it is only "queer", as I always thought that it was a boot utility/tool (like Rufus/Unetbootin/etc.) that could "decide" to support (or not support) a specific .iso/Os/distro, not the other way round. :dubbio:

 

:duff:

Wonko



#27 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 04 September 2018 - 12:03 PM

With September having arrived, it is time for a new BETA!

 

Rufus 3.2 BETA:

  • Add RSA-2048 signature validation on all the server downloads
  • Add "Fast zeroing" cheat mode (courtesy of René van der Zee)
  • Add support for XP/Server 2003 x64 ISOs (courtesy of Mattiwatti)
  • Improve ISO extraction performance by preallocating files (courtesy of Mattiwatti)
  • Improve bad blocks check algorithm (from suggestions by AL.Skywalker)
  • Fix progress not being displayed for Sylinux or GRUB downloads
  • Fix application close when cancelling an image scan

For those wondering about XP/2003 64-bit ISO support, when official support for these platforms has all but ceased, I'm just going to say this:

It is provided "as is", because it cost nothing to integrate and I didn't have to spend any time on it. However, if you encounter any issue with it, you are 100% on your own.



#28 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14715 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 September 2018 - 01:42 PM

For those wondering about XP/2003 64-bit ISO support, when official support for these platforms has all but ceased, I'm just going to say this:

It is provided "as is", because it cost nothing to integrate and I didn't have to spend any time on it. However, if you encounter any issue with it, you are 100% on your own.

 

Wheeew, for one moment I thought you were softening up (with age :w00t:) ;).

 

Congratulation for the new release :).

 

:duff:

Wonko



#29 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 11 September 2018 - 03:55 PM

Rufus 3.2 has now been released. You can get it from here.

 

The release ChangeLog is as follows:

  • Add RSA-2048 signature validation on all the server downloads
  • Add "Fast zeroing" cheat mode (courtesy of René van der Zee)
  • Add support for XP/Server 2003 x64 ISOs (courtesy of Mattiwatti)
  • Improve ISO extraction performance by preallocating files (courtesy of Mattiwatti)
  • Improve bad blocks check algorithm (from suggestions by AL.Skywalker)
  • Fix progress not being displayed for Sylinux or GRUB downloads
  • Fix unwanted application close when cancelling an image scan
  • Fix an issue where FAT32 could still be selected for ISOs containing a >4GB file

Enjoy! :rolleyes:



#30 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 17 September 2018 - 12:17 PM

Bugs don't take a break and neither do we → Rufus 3.3 [BUGFIX RELEASE]

  • Fix a regression when processing uncompressed bootable DD images
  • Fix Windows To Go drive creation for ARM64 Windows ISOs

The second issue didn't really require a fast-track release, but the first one did because it meant that Rufus was unable to open uncompressed DD images or  without reporting Failed to scan image, which is a bit of a showstopper...

 

By the way, since it seems a lot of people who ran into this issue weren't aware of it, did you know that Rufus has been able to open .zip, .Z, .gz, .lzma, .bz2 and .xz compressed DD images for quite a few years now?

 

Available HERE.



#31 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 16 October 2018 - 03:43 AM

Due to a targeted DDoS attack against the existing Rufus servers, please be advised that we have had to move our content as well as alter our DNS and hosting functionality, which means that you may find that you have trouble accessing https://rufus.akeo.ieor https://rufus.ie.

 

If that is the case, you are encouraged to visit http://rufus.ie/downloads (That's HTTP, NOT HTTPS, as more work is needed to properly restore SSL) to download the Rufus executable.

 

You may also try http://rufus.ie for the home page (again HTTP only for now), but depending on your browser, it is possible you will may only get an SSL error for that.

 

Obviously, we are working on restoring full web site functionality as soon as we can, and we apologize for the inconvenience.



#32 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 16 October 2018 - 12:23 PM

https://rufus.ie and https://rufus.akeo.ie (which has now been set to always redirect to https://rufus.ie)should now be operational again.

 

There are some minor annoyances (language selection, check for update) that still need to be resolved, but they aren't as high a priority as the rest, and will be sorted at a more leisurely rate...



#33 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 22 November 2018 - 04:52 PM

Been some time, so HERE's a BETA for Rufus 3.4.

 

The ChangeLog for the upcoming version is as follows:

  • Set the default image selection directory to Downloads\ instead of My Documents\
  • Add ARM/ARM64 automatic update support
  • Improve UEFI:NTFS compatibility
  • Update the .appx to include all architectures as well as request elevation
  • Fix broken detection of some EFI based images
  • Fix broken update check due to new server
  • UI and accessibility fixes and improvements

As usual, if you think you encountered any issue with the BETA, PLEASE report it!



#34 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 28 November 2018 - 03:49 PM

Releasing a BETA 2, as there were a few small but annoying device access issues that I wanted to see fixed sooner rather than later.

 

You can find the new BETA HERE.



#35 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 05 December 2018 - 05:28 PM

And Rufus 3.4 has been released.

 

Final Changelog:

  • Set the default image selection directory to Downloads\ instead of My Documents\
  • Add ARM/ARM64 automatic update support
  • Improve UEFI:NTFS compatibility
  • Improve access issues by using VDS to delete all partitions
  • Update the .appx to include all architectures as well as request elevation
  • Fix broken detection of some EFI based images
  • Fix broken update check due to server switch
  • UI and accessibility fixes and improvements

 

It needs to be pointed out that, if you are using an older version of Rufus, and have enabled automatic updates, you will not get the latest update, as our change of server means that the old update check mechanism is broken (and if you really want to know all, the reason behind this has to do with the fact that we no longer control the Content-Type for the .ver files we use for automatic updates, github does, and since github only sets Content-Type according to RFCs, .ver files are defaulting to binary/octet-stream, whereas earlier versions of Rufus were designed to bail out on the update check if the Content-Type was anything other than text/plain).

 

You will therefore have to download the latest version manually. But of course, Rufus 3.4 will be able to detect subsequent updates. I can only apologize for the inconvenience.


  • wimb likes this

#36 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 16 March 2019 - 02:37 PM

It is my great pleasure to announce a BETA for the upcoming Rufus 3.5. It can be downloaded HERE.

 

This release has been a long time in coming due to the following exciting feature (and much less exciting bugfixes) being introduced:

  • Add a feature to download official retail Windows 8.1 or Windows 10 ISOs
  • Add Windows To Go support for MCT generated Windows ISOs
  • Add a notice about the WppRecorder.sys Microsoft bug for Windows 10 1809 ISOs
  • Add a notice about trying to format a drive larger than 2 TB in MBR mode
  • Add a notice about Legacy boot when trying to boot UEFI-only media in Legacy mode
  • Report the full PID and command line of detected blocking processes in the log
  • Fix a potential silent abort when the drive is in use
  • Fix Quick Format option always being active
  • Fix some unwanted file system changes occurring after an ISO had been selected

 

As usual, if you think you have uncovered an issue or are seeing some behaviour that you don't think is expected, you are kindly invited to report it in the GitHub issue tracker.

 

 

Now, since this is reboot.pro, I'm going to expand a little bit on some of those:

 

1. The download feature, which you access through the split button on 'SELECT' is basically accomplished by downloading and running a __signed__ PowerShell script. For those worried about this I am planning to add a blurb about this either in the FAQ or on the Security page to indicate how, even if the server we download the script from is compromised, because we validate its RSA signature before we allow it to run, and our private key obviously does not reside on any remote servers or anywhere in "the cloud", Rufus will never allow a malicious script to run. Also that script is never saved locally, and does not download any remote data except from the Microsoft servers, which makes it very difficult to hijack even if the local machine is compromised. At any rate, if you are paranoid about the idea of running a script, you can just disable the check for updates (which Rufus prompts everyone to accept or reject the first time it runs), as we consider that someone who doesn't want Rufus to contact its servers to check and download new updates probably doesn't want Rufus to download scripts either, and therefore, we use the check for update as a toggle for the download feature.
As to what the feature does, it simply replicates what can be done by visiting https://www.microsof...oad/Windows8ISO or https://www.microsof...ad/Windows10ISO (I would have added Windows 7 as well, if Microsoft weren't such asses about requiring a working serial to get access to the download links), except, unlike what it the case when using a browser, it won't actively prevent you from accessing the retail ISO links if it detects that the platform you are using is the same as the one you are trying to download.
Oh, and for those tempted to say that I could have just use https://tb.rg-adguard.net/public.phpor the Windows download tool from heidoc.net, the problem is that mooching downloading of adguard wouldn't be very nice and I'd be at the mercy of their servers going down (since the heidoc tool also contacts their own servers to get access to the download links) and also, more annoyingly, these guys have taken the approach of concealing how they are accessing the Microsoft download links (closed source, especially for the heidoc tool), whereas I have always made sure that every single thing Rufus does is 100% open and public.
Anyway, for more on this, you can check the script, which is called "Fido" at https://github.com/pbatard/Fido and which I also designed to be run in standalone if you feel like it (though you may want to be aware that the Microsoft servers will enact a temporary ban if they think you request a few too many download links in sequence).

 

2. I am still super pissed at Microsoft having taken the approach of NOT FRIGGING DOCUMENTING the option that one is supposed to use to get their WIM API to be happy with the MCT ISOs' install.esd's. Basically, if you want to use WIMCreateFile() to work with such images (such as applying them), you need to pass a flag I call WIM_UNDOCUMENTED_BULLSHIT with value 0x20000000. That's really all it takes to get the WIM APIs to work and I am this close to believe that Microsoft merely introduced this bullshit flag to prevent developers from being able to work with their MCT ISOs, because it really makes no sense (if it's a matter of wim/esd version compatibility, it can be gotten from the file itself, so that's definitely not the reason). A huge thank goes to the dism++ developers for apparently figuring out that one (though, since that application is closed source, I had to look at the disassembly in IDA Pro to get that detail). At any rate, Rufus should now be able to produce a Windows To Go drive from pretty much any Windows 10 ISO you throw at it.

 

3. As you should know, deleting user's document is not the only think Microsoft botched in the Windows 10 1809 release. Apparently, they didn't bother to properly test Windows To Go mode with 1809 either, because it sure will create BSODs for most people due to whatever they decided to introduce in WppRecorder.sys since 1803. Unfortunately, this is not something they picked with the October re-release, so both releases of 1809 are affected. Oh and it doesn't only affect Windows To Go but it also affects trying to run a regular install from SD media (such as trying to run a regular install of Windows 10 ARM64 on a Raspberry Pi3 -- you do know that you can actually run the full UI version of Windows 10 ARM64 on the Rpi3, don't you?). Anyway, for more on this, you can read this entry from the FAQ, which is the same as the one I linked in the ChangeLog.

 

4. Since I had a bit of extra time, I decided to create an MBR that displays a notice when someone is trying to boot an UEFI-only bootable drive (GPT based), in the protective MBR. Of course this MBR will not be inserted if you are writing in DD image mode, or if you create a non-bootable media, but hopefully it should help people who don't know too much about Legacy vs UEFI and don't pay attention to the type of system they are trying to boot when creating their media in Rufus.



#37 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 4 weeks ago

BETA #2 is now available here.

 

The Changelog hasn't really changed but we're been adding stuff behind the scenes (such as downloading an LZMA compressed version of the ISO download PowerShell script rather than a much larger uncompressed version) as well as small fixes, and of course, a few more translations have been updated.

 

Oh, and as promised, I created an entry on our Security page to detail the steps we are taking to make sure that even as we are downloading and running a remote PowerShell script, this cannot be hijacked for malicious purposes.



#38 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14715 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 4 weeks ago

2. I am still super pissed at Microsoft having taken the approach of NOT FRIGGING DOCUMENTING the option that one is supposed to use to get their WIM API to be happy with the MCT ISOs' install.esd's. Basically, if you want to use WIMCreateFile() to work with such images (such as applying them), you need to pass a flag I call WIM_UNDOCUMENTED_BULLSHIT with value 0x20000000. That's really all it takes to get the WIM APIs to work and I am this close to believe that Microsoft merely introduced this bullshit flag to prevent developers from being able to work with their MCT ISOs, because it really makes no sense (if it's a matter of wim/esd version compatibility, it can be gotten from the file itself, so that's definitely not the reason). A huge thank goes to the dism++ developers for apparently figuring out that one (though, since that application is closed source, I had to look at the disassembly in IDA Pro to get that detail). At any rate, Rufus should now be able to produce a Windows To Go drive from pretty much any Windows 10 ISO you throw at it.

I understand your frustration.  :frusty: 

As I often like to remind, remember that only MS can throw the secret seven:
https://jdebp.eu/Hum...t-monopoly.html

but lately I tend to believe that is due less to malicious intents than to plain incompetence/lack of any form of proper testing, just like the 1809 BIG mess.

 

:duff:

Wonko



#39 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2506 posts
  • Location:Nantes - France
  •  
    France

Posted 4 weeks ago

 

2. I am still super pissed at Microsoft having taken the approach of NOT FRIGGING DOCUMENTING the option that one is supposed to use to get their WIM API to be happy with the MCT ISOs' install.esd's. Basically, if you want to use WIMCreateFile() to work with such images (such as applying them), you need to pass a flag I call WIM_UNDOCUMENTED_BULLSHIT with value 0x20000000. That's really all it takes to get the WIM APIs to work and I am this close to believe that Microsoft merely introduced this bullshit flag to prevent developers from being able to work with their MCT ISOs, because it really makes no sense (if it's a matter of wim/esd version compatibility, it can be gotten from the file itself, so that's definitely not the reason). A huge thank goes to the dism++ developers for apparently figuring out that one (though, since that application is closed source, I had to look at the disassembly in IDA Pro to get that detail). At any rate, Rufus should now be able to produce a Windows To Go drive from pretty much any Windows 10 ISO you throw at it.

 

 

 

After some mad googling a while back I found some doc refererencing this const as WIM_FLAG_CHUNKED = $20000000;

That allowed me to handle esd files in CloneDisk.

But clearly this api is not the best documented one... and it is not tempting to stick to 7z or wimlib whenever possible...

 

And yes, the DISM++ guys are really on top of their games when it comes to push windows api's to their best.



#40 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14715 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 4 weeks ago

After some mad googling a while back I found some doc refererencing this const as WIM_FLAG_CHUNKED = $20000000;

That allowed me to handle esd files in CloneDisk.

But clearly this api is not the best documented one... and it is not tempting to stick to 7z or wimlib whenever possible...

 

And yes, the DISM++ guys are really on top of their games when it comes to push windows api's to their best.

 

Right now google provides these (ONLY two) results:

https://github.com/j...iveConstants.cs

/// <summary>
 /// Create flag to allow cross-file WIM.
/// </summary>
internal const uint WIM_FLAG_CHUNKED = 0x20000000;

and:

https://github.com/j...ft.Wim/Enums.cs

 

 

 

(and the latter page is nowhere to be found), still in cache, get it before it vanishes:

http://webcache.goog...t&hl=it&ct=clnk

/// <summary>
/// Allow cross-file WIM like ESD.
/// </summary>
Chunked = WimgApi.WIM_FLAG_CHUNKED,

:duff:

Wonko



#41 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2506 posts
  • Location:Nantes - France
  •  
    France

Posted 4 weeks ago

Yep, I can recall now this is the page I found.

Now trying to recall how I got there searching for wimapi and ESD...

 

Just in case, sharing below my current wimapi const.

I am pretty sure they are all known by dev guys but just like Rufus, sometime one simple const takes forever to google so ...

 

Just spot that I actually kept as a comment the URL https://github.com/j...iveConstants.cs:)

WIM_COMPRESS_NONE = 0;
  WIM_COMPRESS_XPRESS = 1;
  WIM_COMPRESS_LZX = 2;
  WIM_COMPRESS_LZMS = 3;

  WIM_CREATED_NEW = 0;
  WIM_OPENED_EXISTING = 1;


// WIMCreateFile, WIMCaptureImage, WIMApplyImage, WIMMountImageHandle flags:
//https://github.com/josemesona/ManagedWimgApi/blob/master/src/Microsoft.Wim/WimgApi.NativeConstants.cs
  WIM_FLAG_RESERVED = $00000001;
  WIM_FLAG_VERIFY = $00000002;
  WIM_FLAG_INDEX = $00000004;
  WIM_FLAG_NO_APPLY = $00000008;
  WIM_FLAG_NO_DIRACL = $00000010;
  WIM_FLAG_NO_FILEACL = $00000020;
  WIM_FLAG_SHARE_WRITE = $00000040;
  WIM_FLAG_FILEINFO = $00000080;
  WIM_FLAG_NO_RP_FIX = $00000100;
  WIM_FLAG_MOUNT_READONLY = $00000200;
  WIM_FLAG_MOUNT_FAST = $00000400;
  WIM_FLAG_MOUNT_LEGACY = $00000800;  
  WIM_FLAG_WIM_BOOT = $2000;
  WIM_FLAG_CHUNKED = $20000000;

// WIMGetMountedImageList flags
  WIM_MOUNT_FLAG_MOUNTED = $00000001;
  WIM_MOUNT_FLAG_MOUNTING = $00000002;
  WIM_MOUNT_FLAG_REMOUNTABLE = $00000004;
  WIM_MOUNT_FLAG_INVALID = $00000008;
  WIM_MOUNT_FLAG_NO_WIM = $00000010;
  WIM_MOUNT_FLAG_NO_MOUNTDIR = $00000020;
  WIM_MOUNT_FLAG_MOUNTDIR_REPLACED = $00000040;
  WIM_MOUNT_FLAG_READWRITE = $00000100;

// WIMCommitImageHandle flags
  WIM_COMMIT_FLAG_APPEND = $00000001;

// WIMSetReferenceFile
  WIM_REFERENCE_APPEND = $00010000;
  WIM_REFERENCE_REPLACE = $00020000;

// WIMExportImage
  WIM_EXPORT_ALLOW_DUPLICATES = $00000001;
  WIM_EXPORT_ONLY_RESOURCES = $00000002;
  WIM_EXPORT_ONLY_METADATA = $00000004;

// WIMRegisterMessageCallback:
  INVALID_CALLBACK_VALUE = $FFFFFFFF;

// WIMCopyFile
  WIM_COPY_FILE_RETRY = $01000000;

// WIMDeleteImageMounts
  WIM_DELETE_MOUNTS_ALL = $00000001;

// WIMMessageCallback Notifications:
  WM_APP = $8000; //uses Messages
  WIM_MSG = WM_APP + $1476;
  WIM_MSG_TEXT = WIM_MSG + 1;
  WIM_MSG_PROGRESS = WIM_MSG + 2;
  WIM_MSG_PROCESS = WIM_MSG + 3;
  WIM_MSG_SCANNING = WIM_MSG + 4;
  WIM_MSG_SETRANGE = WIM_MSG + 5;
  WIM_MSG_SETPOS = WIM_MSG + 6;
  WIM_MSG_STEPIT = WIM_MSG + 7;
  WIM_MSG_COMPRESS = WIM_MSG + 8;
  WIM_MSG_ERROR = WIM_MSG + 9;
  WIM_MSG_ALIGNMENT = WIM_MSG + 10;
  WIM_MSG_RETRY = WIM_MSG + 11;
  WIM_MSG_SPLIT = WIM_MSG + 12;
  WIM_MSG_FILEINFO = WIM_MSG + 13;
  WIM_MSG_INFO = WIM_MSG + 14;
  WIM_MSG_WARNING = WIM_MSG + 15;
  WIM_MSG_CHK_PROCESS = WIM_MSG + 16;
  WIM_MSG_WARNING_OBJECTID = WIM_MSG + 17;
  WIM_MSG_STALE_MOUNT_DIR = WIM_MSG + 18;
  WIM_MSG_STALE_MOUNT_FILE = WIM_MSG + 19;
  WIM_MSG_MOUNT_CLEANUP_PROGRESS = WIM_MSG + 20;
  WIM_MSG_CLEANUP_SCANNING_DRIVE = WIM_MSG + 21;
  WIM_MSG_IMAGE_ALREADY_MOUNTED = WIM_MSG + 22;
  WIM_MSG_CLEANUP_UNMOUNTING_IMAGE = WIM_MSG + 23;
  WIM_MSG_QUERY_ABORT = WIM_MSG + 24;

// WIMMessageCallback Return codes:
  WIM_MSG_SUCCESS = ERROR_SUCCESS;
  WIM_MSG_DONE = $FFFFFFF0;
  WIM_MSG_SKIP_ERROR = $FFFFFFFE;
  WIM_MSG_ABORT_IMAGE = $FFFFFFFF;


// WIM_INFO dwFlags values:
  WIM_ATTRIBUTE_NORMAL = $00000000;
  WIM_ATTRIBUTE_RESOURCE_ONLY = $00000001;
  WIM_ATTRIBUTE_METADATA_ONLY = $00000002;
  WIM_ATTRIBUTE_VERIFY_DATA = $00000004;
  WIM_ATTRIBUTE_RP_FIX = $00000008;
  WIM_ATTRIBUTE_SPANNED = $00000010;
  WIM_ATTRIBUTE_READONLY = $00000020;

//MOUNTED_IMAGE_INFO_LEVELS
  MountedImageInfoLevel0 = 1;
  MountedImageInfoLevel1 = 2;
  MountedImageInfoLevelInvalid = 3;


#42 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 4 weeks ago

Thanks.

 

And yeah I also found a reference for WIM_FLAG_CHUNKED after I started to use that flag in Rufus. But I don't think I ever saw any explicit mention that you needed that extra flag (or any extra flag) to open recent install.esd images if you were getting a [0x0000000B] An attempt was made to load a program with an incorrect format error (an error that I made sure to document in the Rufus source so that poor souls wondering why the heck Microsoft's latest WIM APIs seem to be unable to handle Microsoft's recent WIM images might find a clue).

 

Of course, once you've figured out that the flag is needed, you can indeed find other references (apparently can't link to the second one here but it's the one from the GitHub thread) pointing you to the fact that you do want to have that flag to open a .esd, but so far I haven't been able to find any that originates from Microsoft...

 

Also while I agree with Wonko's unlikelihood of deliberate ill intent, I'd still like to hear Microsoft's explanation as to why their WIM APIs might be unable to detect that they need to add the flag on their own (especially if this is tied to opening .esd's as opposed to .wim's which should be easy to detect), or why they couldn't just use a bump in version number for their image format to tell the APIs that a flag might be needed.



#43 Akeo

Akeo

    Frequent Member

  • Developer
  • 327 posts
  •  
    Ireland

Posted 3 weeks ago

And Rufus 3.5 has now been released.

 

The final Changelog is as follows:

  • Add a feature to download official retail Windows 8.1 or Windows 10 ISOs
    (Note: 'Check for updates' must be enabled for the above to be active)
  • Add Windows To Go support for MCT generated Windows ISOs
  • Add a notice about the WppRecorder.sys Microsoft bug for Windows 10 1809 ISOs
  • Add a notice about trying to format a drive larger than 2 TB in MBR mode
  • Add a notice about Legacy boot when trying to boot UEFI-only media in Legacy mode
  • Report the full PID and command line of potentially blocking processes in the log
  • Fix a potential silent abort when the drive is in use
  • Fix 'Quick Format' option always being activated
  • Fix potential change of the selected file system after an ISO has been loaded
  • Fix Win7 x64 EFI bootloader not being extracted in dual BIOS+UEFI mode (Alt-E)

I'll use this opportunity to express my thanks to the people who checked the BETA releases and reported issues.







Also tagged with one or more of these keywords: rufus

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users