The Portable Freeware Collection Forums

I edited the entry again... hope it's final this time

I am Baas wrote:Rufus does not store any settings besides the "Check for Updates" ones. Your edit implied differently. As for the DB entry, it clearly states that Rufus writes "Check for Updates" settings to the registry but it was convenient to omit that, was it not?

All the settings Rufus maintains between uses are stored in the registry. All in this case means everything it maintains between runs. This is as opposed to some apps which will let you maintain some settings in an INI to take portably while some other settings are still stored in the registry. There are multiple apps that do this and, IIRC, several are listed on PFC. I simply chose All instead of Some for that reason.

I am Baas wrote:The same as you were about to notify SYSTEM? Oh please, cut the crap, JohnTHaller. It is clear to me that your motives are not pure and I hope that everyone else here at TPFC sees that too.

Yup. The same way I was going to notify him I did the release even though I was under no legal or ethical obligation to. Except that he'd already seen it after I'd released it just before 11pm and posted about it on PortableApps.com at 5am, 6 hours after I released it, while I was sleeping. Since SYSTEM saw it and posted about it there, I continued to interact with him there. That's also why I posted a possible better icon I mocked up there rather than here, we were already discussing things.

I am Baas wrote:The db entry gives an accurate description of the settings that are written to the registry, unlike your attempt that was (intentionally) vague. It also tells about the workarounds that are being discussed in this thread.

My entry was accurate as all the settings Rufus maintains between uses are stored in the registry. The reasoning is clear as I explained vs apps that allow you to store some settings in the INI vs registry. Your edit, however, was incorrect. "Writes settings to: None" was factually incorrect. It writes settings to the registry (HKCU\Software\Akeo Consulting\Rufus). And there is no setting, command line parameter or environment variable to disable that.

As I said before, if I was looking to start trouble, I could have easily switched the entry to Rufus Portable outright. It wouldn't even be untoward to switch the entry as PFC seems less willing to list apps that don't keep their settings portable than in previous years and several existing entries have switched from the provided Zips to "wrapped" versions of the apps (PA.c, WPP, or similar) due to the fact that settings were not portable in the zip version. I did not switch the entry, though. Nor did even add Rufus Portable as an alternative. I simply hadn't gotten around to posting about Rufus Portable on here or editing the entry to indicate that Rufus Portable was available.

JohnTHaller wrote:

I am Baas wrote:The db entry gives an accurate description of the settings that are written to the registry, unlike your attempt that was (intentionally) vague. It also tells about the workarounds that are being discussed in this thread.

My entry was accurate as all the settings Rufus maintains between uses are stored in the registry. The reasoning is clear as I explained vs apps that allow you to store some settings in the INI vs registry. Your edit, however, was incorrect. "Writes settings to: None" was factually incorrect. It writes settings to the registry (HKCU\Software\Akeo Consulting\Rufus). And there is no setting, command line parameter or environment variable to disable that.

I agree with Baas' entry preference for the wording: I think "No. See forum thread for a workaround" is more accurate than "All settings stored in registry". Although the sum total of settings are update-checking, it's technically accurate to say "All", the workaround for those who are concerned with Stealth status is what's most germane. Additionally, I took it a step further by adding a link to the workaround entry.

Also, I don't get the sense that this edit crossed a line. For example, it would be a conflict of interest for someone to list a version they own/maintain with inaccurate positive aspects and negative ones to the other.

JohnTHaller wrote:It wouldn't even be untoward to switch the entry as PFC seems less willing to list apps that don't keep their settings portable than in previous years and several existing entries have switched from the provided Zips to "wrapped" versions of the apps (PA.c, WPP, or similar) due to the fact that settings were not portable in the zip version.

First, this doesn't reflect a policy change: as a volunteer website, we take what assistance we can get and if the majority of active users list a wrapper version, I really don't want to go against that. As indicated by this thread, the main push to go for non-wrapper versions is just to avoid being a mirror for other sites and to provide an alternative for people who prefer non-wrapper options.

Second, the presence of more and more wrapper-based programs may have something to do with the push on PA to add more and more programs. This has simply made it more likely that portable software that gets added to the PFW database will be at least initially a PA-created selection. I think this would happen for WinPenPack, Lupo, or any other project that aggressively expanded their list of portable offerings.

webfork wrote:I agree with Baas' entry preference for the wording: I think "No. See forum thread for a workaround" is more accurate than "All settings stored in registry". Although the sum total of settings are update-checking, it's technically accurate to say "All", the workaround for those who are concerned with Stealth status is what's most germane. Additionally, I took it a step further by adding a link to the workaround entry.

I see your point, webfork. I was just trying to distinguish between apps that can be configured to store some settings in a file but insist on storing others in the registry, rendering them sort of/mostly portable.

The 'workaround' entry is still incorrect, however. The workaround link only works around Rufus prompting you how you want to update on each new PC. It will still save your updater preferences on every PC you run it on and not maintain them between PCs if you select to change them. The linked workaround has nothing to do with Stealth and is better suited to being in the description as a fix for Rufus prompting for your update selections on every new PC.

The only way around it writing preferences on each PC is to use a wrapper as with Rufus Portable or to recompile the code with something checking for a portable settings file, a blank 'portable' file stub, or the app exe being renamed as rufus_noupdate.exe or similar. This would be relatively easy for a coder, but not something we could suggest end users do. We could suggest it to the publisher, however.

JohnTHaller wrote:The 'workaround' entry is still incorrect, however. The workaround link only works around Rufus prompting you how you want to update on each new PC. It will still save your updater preferences on every PC you run it on and not maintain them between PCs if you select to change them. The linked workaround has nothing to do with Stealth and is better suited to being in the description as a fix for Rufus prompting for your update selections on every new PC.

Prompting for update check does not affect portability. Alt + R before exiting Rufus will clear the registry entries

JohnTHaller wrote:The only way around it writing preferences on each PC is to use a wrapper as with Rufus Portable or to recompile the code with something checking for a portable settings file, a blank 'portable' file stub, or the app exe being renamed as rufus_noupdate.exe or similar. This would be relatively easy for a coder, but not something we could suggest end users do. We could suggest it to the publisher, however.

Changing the default updater value to "disabled" would solve a lot of the issues. It should anyway be the user's choice/responsibility to check for a newer version IMO.

I am Baas wrote:Prompting for update check does not affect portability. Alt + R before exiting Rufus will clear the registry entries

Ah, that should be linked from the Stealth section and then the other workaround about renaming it to disable updates question should be linked from the main section. They're two different workarounds for two problems. I think that was some of the confusion as the entry when it was last updated was still wrong and only talked about working around the update prompt check, which is unrelated to stealth. The onus would be on the user to remember to hit ALT-R before every exit of Rufus, though.

I am Baas wrote:Changing the default updater value to "disabled" would solve a lot of the issues. It should anyway be the user's choice/responsibility to check for a newer version IMO.

I think most software these days defaults to check for updates. It makes sense as most PCs are nearly always internet-connected. Some software takes the polite way and asks you how you want to update on first run like Rufus and VLC. The only issue here is that said selection isn't portable in the case of Rufus. Having one of the other options like setting it portable or renaming it to _noupdate would solve that bit. As would using a wrapped version.

EDIT: The above all laid out, are there any objections for moving mentioning to rename the EXE to rufus.exe to avoid the update check to the extract instructions and then mentioning hitting ALT-R on every exit to the Stealth workaround section? I don't think we need to link to the forum topic as it is easily explained in a single sentence in the entry and this would make the entry fairly complete and easier to understand for the end user with both workarounds included.

JohnTHaller wrote:EDIT: The above all laid out, are there any objections for moving mentioning to rename the EXE to rufus.exe to avoid the update check to the extract instructions and then mentioning hitting ALT-R on every exit to the Stealth workaround section? I don't think we need to link to the forum topic as it is easily explained in a single sentence in the entry and this would make the entry fairly complete and easier to understand for the end user with both workarounds included.

I do. Explained here.

I am Baas wrote:

Ruby wrote:If you run rufus.exe (no version in filename/first run) you will not get the update settings prompt and default values are applied.

The default value is "Daily Check for Updates"... Rufus will call home a quick minute after having been launched. The "CommCheck" and "UpdateCheckInterval" values are written to the registry no matter what.

I'd rather run rufus_v1.x.x.exe, get the prompt, decline, do what needs done, press Alt + R (this will delete the registry entries), exit Rufus.

I am Baas wrote:I'd rather run rufus_v1.x.x.exe, get the prompt, decline, do what needs done, press Alt + R (this will delete the registry entries), exit Rufus.

I think I see what you mean. But whether you rename it to rufus.exe or not to disable the prompt is still unrelated to stealth (since the registry keys are written either way). You're right, though, some folks who don't want it calling home would rather see the prompt and be able to say no.

That in mind, I think this would make sense for stealth:

Stealth: No, writes updater settings to HKCU\Software\Akeo Consulting\Rufus. Workaround: Press ALT-R before exiting Rufus to remove the registry entries.

And then something at the end of the description like:

To avoid Rufus asking whether to update on each PC, rename rufus_v1.x.x.exe to rufus.exe. This will cause Rufus to check for an update when launched without asking. Registry entries for the update check will be created whether or not Rufus is renamed. Pressing ALT-R just before exiting Rufus will clear them.

I think it may be a bit to wordy, but would be better than linking to the middle of the forum topic. And it gives the user the option of renaming or not letting them know what it does rather than just having renaming be a part of the install instructions.

Version 1.3.2 (2013.01.27):
Fix support for newer ArchLinux ISOs, that was removed in 1.3.1
Add support for UEFI boot, as well as GPT.
What this means is that Rufus can now produce UEFI bootable UFDs from EFI compatible ISOs, such as Windows 7 x64, Windows 8, ArchLinux, etc.
The first partition is now always aligned to 1MB (unless advanced options are used)
Internal refactoring and fixes

Booting Linux using UEFI on some Samsung laptops may cause problems (read: BRICK)

source: H-Online

~Ruby

Thanks yet again, Ruby. This is a lifesaver, that issue affects precisely my current lappy's model...

Hi,

I'm the author of Rufus, and I've only recently discovered this thread.

First of all, thanks for the work you've done here for promoting the app and making it portable. It's always appreciated!

Since I'm here, I'll just point a few things:

• I see that the latest version for portable is v1.4.0.
  Though the changes between 1.4.0 and 1.4.1 may appear minor, I would strongly encourage to update it to v1.4.1, as v1.4.0 actually contains a quite nasty bug that may corrupt the content it extracts from ISO9660 images (including non-Linux ones). I'd really hate to see Rufus users end up with corrupted data simply because they weren't using the last version.
• If you wanted to find out about what commcheck or other things do you could simply have asked me...
  Time permitting, I tend to welcome feedback, no matter what it is about, and I did leave means of contacting appear fairly prominent on the homepage for that reason. But yeah, as commented in the code, this just detects whether we have the ability to access the registry, since you never know how various machines might be locked down. I also see you found about Alt-R to clean the registry. FYI, there are a bunch of other cheat modes documented in the FAQ. The rufus_xyz.exe prompt vs rufus.exe no-prompt is also explained here. And yes, besides entries below HKCU/Software/Akeo Consulting/Rufus/, the app may involuntarily modify other registry entries as it temporarily disables the prompt you get (autorun) when inserting an USB drive. This is done using Local Group Policies, as this is what Microsoft officially recommends to use to do so. Even though Rufus makes sure it cleans the LGP settings on exit, this may leave the registry in a different state than when the app started, due to Microsoft's implementation of LGP. Short of not using the method Microsoft advocates for altering autorun settings, there's not much I can do about that.
• Rather than have 2 separate codebases for portable and non-portable, I wouldn't mind trying to meet you guys halfway and try to include the changes you'd like to have for portable in the actual application repository. Maybe we could use a trick similar to rufus.exe vs rufus_xyz.exe and have a rufus_portable.exe, that would essentially be the exact same binary, but that would write settings to a file instead of the registry and alter operations that you'd like altered for portable. By the way, as per the GPL, if you modify the source in any way, you must publish your modified source. My understanding is that the portable version from this site was modified to not write to the registry, but I'm not sure where I can find the source for these changes...
• You might be interested to know that the upcoming version (1.4.2) will write one more setting into the registry to preserve the language selected by the user to run the application in. This is done so that people who want to run Rufus in a language that's different from their OS' don't have to reselect it every time. As you can understand, there will probably be more settings ending up in the registry as time goes by, since this is the way Windows apps are designed to work.

Where possible, I'd like to keep you guys happy with regards to Rufus and portability, so if there's anything you'd like to have, feel free to ask. Can't promise it will happen fast (Alas, I can't develop Rufus all day long), but I'll see what I can do!

Akeo wrote:First of all, thanks for the work you've done here for promoting the app and making it portable. It's always appreciated!

Akeo wrote: I see that the latest version for portable is v1.4.0.
Though the changes between 1.4.0 and 1.4.1 may appear minor, I would strongly encourage to update it to v1.4.1, as v1.4.0 actually contains a quite nasty bug that may corrupt the content it extracts from ISO9660 images (including non-Linux ones). I'd really hate to see Rufus users end up with corrupted data simply because they weren't using the last version.

Akeo wrote: By the way, as per the GPL, if you modify the source in any way, you must publish your modified source. My understanding is that the portable version from this site was modified to not write to the registry, but I'm not sure where I can find the source for these changes...

Rufus Portable is not "from this site". It's from PortableApps.com that belongs to John T. Haller.

I have told them about Rufus 1.4.1.

Regarding the source code: PortableApps.com has made Rufus portable by using PortableApps.com Launcher that exports registry changes into a file when you exit Rufus and restores them (potentially on a different computer) right before Rufus is launched next time. They haven't touched Rufus's source code at all. Yet, they do redistribute the source code as the GPL requires the source to be redistributed even if it hasn't been modified.

http://portableapps.com/apps/utilities/ ... ad_details

Rufus Portable download page wrote: Source Code: PortableApps.com Launcher, Rufus

The final bit of "source code" is the program-specific PortableApps.com Launcher configuration. It is bundled with each program: in the "Other\Source" directory as well as in "App\AppInfo\Launcher" where the Launcher actually reads the configuration.

Akeo wrote:As you can understand, there will probably be more settings ending up in the registry as time goes by, since this is the way Windows apps are designed to work.

Configuration files in %APPDATA% are common as well. Some debate: http://stackoverflow.com/questions/2684 ... s-registry

SYSTEM wrote:I have told them about Rufus 1.4.1.

Thanks. It looks like they have just updated their version to 1.4.1 now.

They haven't touched Rufus's source code at all.

OK. I guess the saving and restoring the registry settings to/from a file is fine then. And thanks for the links.

Configuration files in %APPDATA% are common as well. Some debate: http://stackoverflow.com/questions/2684 ... s-registry

I think using APPDATA is fine when you have a lot of settings to store, and really need to preserve these settings on the next launch, but as far as Rufus is concerned, none of these settings are that important between sessions (as of 1.4.1, all of the settings are for the update check, and 1.4.2 will add a language setting that's only really one click away in the main UI, and that's only there for the limited cases where people don't like the default from autodetection). Plus I think APPDATA works better for applications that come with an installer, as you can have the uninstaller ask the user about deleting the APPDATA files. But of course, Rufus does not need installation, so if I went the APPDATA route, users would be left with yet another file they have no idea about. On the other hand, a lot fewer users are going to look for orphans in the registry, so it's not that big a deal to have leftovers there.

But my main beef with APPDATA, really, is that it'd add yet another file that the vast majority of users won't care about (since they didn't explicitly create it), yet that will end up being indexed and potentially catalogued along with their very valuable data. It is my belief that, the less additional useless data an app adds to a filesystem, the better it is, so that what users are left with is mostly data they willingly created. To that extent, if you have a very minimal amount of data to store for app settings, using the registry is the prefect solution.

Besides, Microsoft has changed its mind so many times on where on the filesystem application settings should be stored (I'm still not sure what the difference is between Local, LocalLow and Roaming) that, even today, using the registry looks like best way to future-proof your app. The current annoyance (Vista or later) about old apps storing their .ini in C:\Program Files only to find out that the .ini file in there is read-only and that the actual editable version resides somewhere you'd never guess on your own (I have to keep a blog post to remind me of that location), has left more than one developer worried about trusting the filesystem approach...

Like it or hate it then, and I'm not speaking just for Rufus, the registry is here to stay. And IMO, that's because it does serve its purpose rather well as a convenient centralized and compartmentalized placed for apps to store their settings.

Hi Akeo,

We're distributing Rufus Portable over at PortableApps.com. As SYSTEM helpfully explained above, we use our PortableApps.com Launcher to make the registry settings portable between PCs, which also ensures nothing is left behind. The PA.c Launcher is also open source under the GPL. And the PA.c Installer used to package it into a .paf.exe is also open source under the GPL. For some details on why we package things this way, we have some information here:
http://portableapps.com/about/what_is_a ... app#whypaf

If you're interested in distributing it yourself, we'd be happy to turn it over to you. Apps in our format can work with our platform and its built-in app store and updater as well as by itself or with another standalone portable menu, so you could distribute it as your portable version right on your site. All our tools are fully open source under the GPL and built using only open source tools, so you won't need to introduce any closed source bits to your build toolchain. And you won't need to change your code at all nor write any code to use our tools. Rufus is portablized without any custom code, just simple INI files that tell it how to run it (as admin) and what registry keys to capture. You can build it and host it yourself, we can host/build it for you or one of each. You may wish to let us continue hosting it on SourceForge, though, as it's had 216,000+ downloads since we introduced it in the beginning of the year, which can add up in terms of bandwidth costs.

Just let me know what you prefer. I can also answer any questions you may have. You can PM me on here or contact us via email at developers_developers ... at sign ... portableapps.com.

One note: Please forgive any slowness in replying or grammatical errors due to pain medication

Best,
John

Hi John,

Thanks for the details.

I think I'm more confident in leaving the portable aspect of Rufus in your hands, especially as you seem to have it well squared out, and there's no extra code needed. While I have the capacity for extra downloads, I don't see much need to also have the portable version of Rufus hosted on my site (unless you really want to) especially as this means that, if my server ever goes down, people should at least still be able to pick the portable version of Rufus...

As I pointed out above, if you think you ever need something specific to make the app more portable, don't hesitate to let me know. Also, in case it matters to you, I'm planning to release v1.4.2 sometime around mid January. But besides the new registry setting for the language, which should be handled automatically with your current framework, I don't believe there's anything you should have to worry about for portability.

Regards,

/Pete