77 replies to this topic

[Akeo]

(Once again, I will start a new thread, since this is a major version and the old thread is probably long enough...)

 

It is my great pleasure to announce the immediate release of Rufus 3.0!

 

A lot of hard work went into this new release, which saw a complete redesign of the GUI, to hopefully make it more intuitive and friendlier, as well as a bit more modern.

 

Of course, we can't mention this new release without expressing our thanks to all the people who helped us with it, in one way or another (some of whom belong to this forum), and especially the many translators who did a tremendous  job for this new version!

 

The full Changelog for the 3.0 release is as follows:

• UI redesign to follow the flow of user operations (with thanks to Fahad Al-Riyami for the concept)
• Drop XP and Vista platform support
• Switch all downloads to SSL and use https://rufus.ie as the new base URL
• Add ARM64 support for UEFI:NTFS
• Fix delays when querying floppy drives during device enumeration
• Improve support of efi.img files on Linux ISOs
• Improve support for non-ISO9660 compliant openSUSE Leap ISOs
• Improve translation support and remove manual positioning
• Internal fixes and improvements

Feel free to head to the official website to download this new release. I hope you will agree that 3.0 is a major improvement on the previous version and was worth the wait.

 

And as usual, if you think you have found an issue, feel free to report it in the github issue tracker.

 

Enjoy!

[Akeo]

Aaand it's already time for an update, therefore new BETA!

 

A bit earlier in our release cycle than usual, but the GRUB-based ISO extraction bug below is a fairly major one, which is better fixed sooner rather than later.

 

Here is the full ChangeLog for Rufus 3.1 BETA:

• Fix extraction of ISO content for GRUB based ISOs (Manjaro, Kaspersky, etc.)
• Fix text being truncated on some dialogs (mostly Russian and Thai)
• Add detection & warning about the Controlled Folder Access Windows 10 feature
• Improve retry attempts for transient errors
• Update GRUB 2.0 and Grub4DOS to latest
• Update libcdio to latest

Download HERE. Report issues or bugs HERE.

[Akeo]

Rufus 3.1 has now been released.

The final ChangeLog for this version is as follows:

• Fix extraction of ISO content for GRUB based ISOs (Manjaro, Kaspersky, etc.)
• Fix text being truncated on some dialogs (mostly Russian and Thai)
• Add detection & warning about the Controlled Folder Access Windows 10 feature
• Improve retry attempts for transient errors
• Increase size of the ESP to 300MB, for Windows To Go drives partitioned as GPT
• Update GRUB 2.0 and Grub4DOS to latest
• Update libcdio to latest

[Blackcrack]

cool, thank you !

[Pavel Azanov]

Thank you, great work!

[Tokener]

Dear Akeo,

thanks for sharing.

 

Regards  T.

[derockere]

Thanks for sharing.

[Hunter23071985]

Thank you, great work!

Is it possible to write several ISO (Win7,8.1,10) + several PE (Win, KAV) to one bootable USB drive?

[Mcasper]

Great job.

 

Thank you very much.

 

PS : There is a problem to download rufus.exe. I can download only a portable version.

[Akeo]

There is a problem to download rufus.exe. I can download only a portable version.

According to my server's log (which shows people have no issue downloading any of the executables), the problem has to be on your side.

Please make sure you tried with a different browser and from a different computer.

[Mcasper]

According to my server's log (which shows people have no issue downloading any of the executables), the problem has to be on your side.

Please make sure you tried with a different browser and from a different computer.

 

Now i tried with the same browser and it was ok. I download rufus 3.1.exe.

 

Thanks.

[RainyShadow]

What is the last XP-compatible version?

Did you drop XP and Vista because of some super important missing functionality, or just to be "modern"?

[Akeo]

What is the last XP-compatible version?

2.18. This is indicated in the downloads repository of the website, where you can find ALL the versions of Rufus that were ever publicly released (outside of ALPHAs or BETAs since it makes no sense to keep those available).

 

Did you drop XP and Vista because of some super important missing functionality, or just to be "modern"?

Lately, it seem like a lot of people are under the impression that we updated the UI just for eye candy, so let me address that.

1. The UI redesign is a process that took us no less than 5 years to complete. In other words, because of users complaining that the UI was confusing (and that issue is just the tip of the iceberg - we got at least one complaint about it per month from the moment we added ISO support in Rufus), we've really been wanting to redesign the UI for a long time, but we knew this would be a very arduous and time-consuming process, which is why we only managed to find the time for it starting late 2017. Of course that may seem irrelevant to your Vista question, but I'm coming to that. All this to say: the first thing you need to understand is that the UI redesign did not come about as a "Gee, we're running out of new features to add... Oh I know, let's just redo the UI, that'll make it look like we've added something new!".

2. For the past few years, we've also been struggling to keep the code compatible with XP and Vista. There are tons of useful API calls that have been introduced with Vita, and even more so with Windows 7 (and even more interesting ones with Windows 8, which is the main reason why Rufus does not provide Windows To Go support on Windows 7), that we had to spend a lot of time, first, adding workarounds for and, second, maintaining these workarounds. You can find an example of that here (being mindful that the changes in stlg.c are not being listed by default on github... because there are just too many of them!). And that example doesn't even take into account most of the extra work we had to do in basically having to maintain and test 3 major types of UI (XP, Vista/7 and 8/10), each with their own quirks (because, of course, Microsoft fiddles with the position and size of your UI controls between Windows versions, which you have to tediously check and compensate for), and which is another whole story in itself (for instance, the introduction of Segoe as the standard system font in Vista has required us to spend days battling with XP vs. Vista_or_later font issues).
In other words, we did wait as long as we could for people to move away from XP (since Rufus, as tool that allows users to upgrade XP to a different version of Windows or a different OS, was a bit special when it comes to needing to provide extended support for XP), before being able to, at long last, free up valuable development time by no longer having to validate that Rufus works as advertised (and looks okay) on XP/Vista. I'm going to go on a limb here and assert that few people have a good idea of how time consuming testing that your application actually works as expected on FIVE different platforms (XP, Vista, 7, 8/8.1, 10) really is: As a developer, it takes WAY too much time and it's also a complete pain in the ass, even more so if you also care, as we do because people are moving to 4k monitors, about having your UI also look good at different zoom factors (because now you have to multiply these 5 platforms with at least 3 different zoom factors ⇒ Goodbye sleep, I hardly knew ye!)

3. The UI look and feel we picked, which we had no idea we would use when we started on the UI redesign trail more than 5 years ago, and which is still internally based on using the good old Win32 APIs that literally date back to Windows 3.1 (rather than all the "modern" UWP way of doing thing you seem to see everywhere these days), is the current look and feel that Microsoft applications seem to be moving towards, since there exists a major push from Microsoft towards using the Fluent design system. So, we are mimicking that as best as we can in the hope that, in a couple years time, it will feel just as familiar to Windows users as the general look and feel of whatever other recent app they chose to download and run that day. The goal here, since a UI redesign is an excruciating process that requires way more work than people imagine, is to avoid having a flurry of Windows 11 users coming to us and asking "Why does Rufus look so ugly and dated on my shiny OS? Can you please update it to look like what Microsoft and most other app developer are doing?".

So, I hope that explains the motivations behind the UI redesign in a nutshell. Of course, there are other factors I could talk about, such as using this opportunity to also modernize our custom localization framework (whereas translators had to resize and reposition controls manually until now). And then we also needed to make provisions, in the UI, for the day we add persistence support for Linux distros as well as other features that I'm not going to comment on, but that we should be in a much better position to implement now that we have freed some development time by no longer having to test or implement code workaround for platforms, that, by all means, should be considered completely obsolete.

[Blackcrack]

<joke>It looks so ugly you should orient yourself on the Reactos and Microsoft let the hump slip down</jocke> *bg*
it is ever more important for the Peoples and the Programmers to become more speed in development of reactos for making faster to have usable and a independent WinNT for the free/open software and safety the informations of Peoples .. also to have maybe a more stable surface like you told Akeo and not to have every changeing's in designs ..
How ever, you and your group of Programmer have found so far the best way between.. maybe it is a option to use QT and the possibility to use a common theme engine in QT .. a Explorer and a Surface for the People's in QT and therewith also a theme-possibility would maybe also not bad .. but this is a idea for the future..
at moment, could you done not better ! *shoulder tapping/pat on the back* 
 

 
best regards
Blacky

[Akeo]

QT: No, just no. This would make the size of the application EXPLODE. Plus, since the QT people are incredibly unfriendly towards the use of a static library (yeah, it's doable, but boy is it painful to achieve!), we'd have to add an installer, which is the last thing we want to do with Rufus. We looked into QT, multiple time, and it's just not a good fit, especially as we're not cross platform and there is no reason why the executable size should become much larger than our current 1 MB (which we think is already large enough for a mere bootable driver creation utility).

 

You might as well ask us to use Electron here, which, actually, is a much more attractive solution than QT in terms of easing up the life of an application developer. After all, who cares if end-users have to download a 100MB file just to display "Hello World"?...

 

With regards to ReactOS, I really REALLY appreciate the project (and I try to contribute where I can), but I have a couple issues with it:

 

1. They simply don't have enough developers. This is not DOS that you are creating a clone of here, so you need the support, and especially financial contribution of someone like Google (or, if they actually had the balls: Intel) to get somewhere. Without developer investment from a large multi-billion software company, I find it very hard to believe that the effort can succeed, because, currently, they can't even manage to play catch up with proper Windows XP compatibility. For the record, Rufus 2.18 isn't even usable on ReactOS at this stage, as ReactOS fails with the most basic thing we can ask of an OS: returning a list of devices...

 

2. If they actually wanted to make it more attractive for people to test ReactOS, they would spend some effort on making sure it can be run from an USB Flash Drive. This is actually the main reason I added ReactOS boot loader support in Rufus, as I was really hoping they were smart enough to realize that a Windows To Go capability from an XP-like ReactOS would become invaluable to people (just like the ability to quickly create a bootable FreeDOS USB drive can be a life saver). There are probably tons of Linux users who would like nothing better than have the ability to quickly run a Windows application from a bootable USB container, when they find that WINE is not working. Yet (unless I am very mistaken, as I have not tried that again lately), and as has been the case for over 5 years now, it just doesn't seem possible to boot ReactOS from an USB Flash Drive without producing a BSOD. So I really have to wonder: What is the point of creating an Open Source implementation of Windows if you can't even recognize that the first thing your users will want is the ability to boot it from USB? IMO, this is the number 1 feature that ReactOS should focus on if they want to both make the whole prospect of using that OS a lot more inviting, and have more people contributing. For the record, because I'd really like to help the project, I've been trying to find time to look into why ReactOS can't boot from USB, but this requires A LOT of investment development-wise, and I just haven't managed to justify allocating the 2 or 3 weeks full-time work that I figure would be needed to investigate that (See point #1).

 

All of the above means that I am currently not very hopeful for ReactOS to actually manage to get anywhere. Possibly, they might get "decent" XP and/or Vista emulation in 5 to 10 years, but IMO, it'll be way too late by then, and I really can't fathom why companies who have A LOT to gain from a non Microsoft-controlled Windows-like OS (<cough>Google<cough>, <COUGH>Intel</COUGH>) are not massively investing into making sure that ReactOS has the development staff a project of this magnitude requires.

[RainyShadow]

Thanks for your answer.

About my second question, it wasn't because of the UI at all. I haven't even tried the new UI as i mostly run XP and rarely boot 7.

It's just that more and more devs drop compatibility with the older platforms, often without obvious reasons - just to join the flow dictated by M$

[Blackcrack]

uuuhh was just a idea, but the modern times in x64 ... well 100MB for "Hello World" be today normal, because the backgroundprogram for NSI *lol*

okey, forget the QT *very big grin*

[Akeo]

It's just that more and more devs drop compatibility with the older platforms, often without obvious reasons - just to join the flow dictated by M$

It's a shame that people seem to think that, so let me see what I can do to dispel the idea that developers are being somehow forced into dropping obsolete platforms by Microsoft:

1. Microsoft has almost no influence on what developers do. Developers simply go where users are. Which means that, once users move to more current platforms, developers follow them there. That's actually part of the reason we're having such a hard time getting rid of XP users, because, since Vista was more or less a dud, Windows users did not move to that platform as they should have, which in turn resulted in developers not spending too much time updating their applications for Vista (if at all), which in turn, seems to have given the false impression to XP users that they would continue to see developers care about their platform forever. Of course that all changed when Windows 7 (and to a lesser extent Windows 10) became the platforms most people were using, but it seems that, by that time, it was a bit too late to make XP users realize that, no matter how vocal they might be, developers have very good reasons to want to drop a platform that had long ceased to see a significant crowd. In the development world, especially for free software, there are no provision for minorities. At all. So it really goes like this: If Microsoft does a proper job, users naturally migrate to newer versions of Windows and developers follow in turn. This is quite different from the "Microsoft is coercing developers to only develop for newer platforms (which they genuinely have no means of doing) so that it'll force users to migrate to these new platform" proposal that seems to be put forward here and there...

2. Now, I must also stress out a point that a lot of non developers seem to miss: Developing for a platform is not "fire and forget" (in other words, it's not because you once ensured that your application worked for XP and Vista that keeping it compatible with XP and Vista is going to be a ball in the park). As soon as, as a developer, you follow your users to the platform where they congregate, while trying to support the older ones, your development process becomes something like this:

• Have an idea for a cool new feature
• Spend days/weeks of hard work adding it, running it on your development platform (which would be a recent version of Windows)
• Feel somewhat satisfied that you have accomplished a good job, and prepare for some well deserved rest
• Before you do that, just in case, run a test on the older platforms. But you're pretty sure that it won't be needed because, as an experienced developer, you've been careful enough not to introduce any changes that should have broken behaviour on older version of Windows.
• Find out that, not only the new feature does not work at all on the old platform, but it has also managed to break some of the existing stuff that was working before, (since development is never restricted to adding only new code -- you're always going to modify existing code)
• Say goodbye to rest, and curse yourself for having decided to support whatever old version of Windows you are now going to have to spend a couple hours either fixing your code for, or, in many cases, add hideous workarounds for...

With XP, this happened to me way more times than I'd care to mention, ranging from finding that XP's SSL libraries were too obsolete to work with my download server (and I'm not even going to start on the absolute FLAK I got from some users, for delaying full SSL support until after I could drop XP), or UI elements that happened to disappear for no reason, or even getting complete garbage on XP when printing a mere 64-bit number on screen, which is something super basic that you would never ever expect to fail...

So please remember this, while it may look like there shouldn't be much to keeping backwards compatibility, backwards compatibility in Windows only goes one way. This means that, as long as you never ever update your code, you might be able to get away with it... But the minute you change one line and recompile, you are pretty much doomed!

All this to say that, developers are not migrating away from older platforms because Microsoft is pushing them, but because it's just too much of a pain in the ass to keep things working there, when your main activity consists precisely of altering code that, no matter what you do, IS going to end up breaking things on these platforms.

[Hunter23071985]

Akeo, can you answer to post # 8 - is it planned or not?

[Akeo]

Is it possible to write several ISO (Win7,8.1,10) + several PE (Win, KAV) to one bootable USB drive?

Ah, sorry, I forgot to reply to that one.

 

This question is answered in the FAQ.

[Hunter23071985]

Akeo, thanks for the response...

[Goodwin]

Nice work! I've been using Rufus for years now and it's always been good to me. Thanks for the update. Diggin the new GUI. 

[TheHive]

Rufus 3.1.1320p, Burned ISO Win 8.1 to usb. Copying Successful. Easier to follow layout.

[Wonko the Sane]

In theory, first saying in publicity:

 

I don’t care what they say as long as they talk about me.

 

but - only for the record/FYI - this mentioning of Rufus (and Unetbootin BTW) is - to say the least - "queer"  :

 

https://kaosx.us/news/2018/kaos08/

 

 

To create reliable installation media, please follow the instructions from the Download page. KaOS ISO’s do not support Unetbootin or Rufus, and DVDs need a burn speed no higher than 4x.

 

Wonko

[Akeo]

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.