Applications that write to the registry, are they portable?

Discuss anything related to portable freeware here.
Message
Author
User avatar
Andrew Lee
Posts: 2212
Joined: Sat Feb 04, 2006 9:19 am
Contact:

#31 Post by Andrew Lee » Sat May 05, 2007 4:55 am

Just saw this comment for XnView by tripex. Thought this would be a better forum to discuss the topic instead of cluttering the entry with comments.
tripex: IrfanView is not stealth or even just portable when you activate file associations or shell functions. For this the exe has to be alway on the same place. On a fresh machine or if you move the app folder you need to reregister your desired file associations and of course they are written to the registry. ALL other settings are portable via ini.
I don't really understand the logic behind this comment, so maybe we can work it out here.

We all know that file associations and shell extensions are not portable. So if you ask Irfanview to register file associations or shell extensions, it is assumed you are prepared to deal with the non-portability.

On the other hand, if you value portability a lot, then you should not ask Irfanview to register file associations or shell extensions. So what exactly is the problem? Are we asking the author of Irfanview to figure out a way to do file associations and shell extensions portably (which technically can't be done), or are we asking the author of Irfanview not to provide these functions (which might be useful to some users)?

cmmehl
Posts: 128
Joined: Sun Feb 19, 2006 7:26 am

#32 Post by cmmehl » Sat May 05, 2007 5:23 am

I agree with Andy - quite often the question of relative paths is not essential. It is however a good indicator whether or not the application has been designed from the beginning to be truly portable ...

It can be annoying, though, when some of the settings write hard-coded paths - so even if you can carry the settings around, this is not necessarily of big use. I'm thinking of default directories, like for saving or opening etc ... As long as the core application works portable, however, I think there is no reason to take the predicate "portable away :)

Where I slightly disagree with Andy is that information about relative paths belongs to the comment section. I rarely open the comments, too often there's just useless comments there. In my opinion such info belongs to the synopsis, and if you're already considering new Boolean fields, relative path respect could be another such optional field.

Have a nice week-end all!
Chris

tripex
Posts: 16
Joined: Tue Aug 08, 2006 10:51 pm

#33 Post by tripex » Sat May 05, 2007 9:47 am

Andrew Lee wrote:

To clarify, for example, if you have been working on a document called f:\docs\work.doc, so this goes into Writer's MRU.

Now you move to another machine. Your USB drive gets assigned the letter "g". When you use the "Recent documents" to try to load "work.doc", you will find it doesn't work because it is hard-coded to "f".
Is there any reasonable way to avoid this problem and keep using the MRU function? I don't think so, because when you work on f:\docs\work.doc the program usually don't know, that F: is the drive where the software is started from itself. It can pre-check, if it is possible to use relative paths, though I have the feeling this can create other fatalities. And even with relativeness paths/checks it will NEVER work on non relative MRU entries anyway.
But I admit I use the MRU seldem or never.

If I understand you right you discuss about the portability of applications that don't do a pre-check to use relative paths in the MRU?

User avatar
Andrew Lee
Posts: 2212
Joined: Sat Feb 04, 2006 9:19 am
Contact:

#34 Post by Andrew Lee » Sun May 06, 2007 5:29 am

Where I slightly disagree with Andy is that information about relative paths belongs to the comment section. I rarely open the comments, too often there's just useless comments there. In my opinion such info belongs to the synopsis, and if you're already considering new Boolean fields, relative path respect could be another such optional field.
OK, while I am at it, might as well add a new field to the database for this.
If I understand you right you discuss about the portability of applications that don't do a pre-check to use relative paths in the MRU?
Well, cmmehl brought up the point that registry usage is not the only factor affecting portability, another possible factor is support for relative paths. My reply to him was that for some apps (eg. program launchers, MP3 players), it is clear-cut that relative path support is important for portability, but for other apps, it is less clear-cut. I brought up the example of MRU implementation in many apps, include OpenOffice, and argue that it is not clear-cut whether the usage of absolute paths in their MRU implementations detracts from their portability. Some people might actually be annoyed enough to call it non-portable, while others (like myself) couldn't care less.

User avatar
Andrew Lee
Posts: 2212
Joined: Sat Feb 04, 2006 9:19 am
Contact:

#35 Post by Andrew Lee » Sun May 06, 2007 5:47 am

cmmehl, regarding your comment about Save2ftp, the app indeed does not support relative paths (eg. ..\..\docs\*.*), but it does support absolute paths without drive letters (eg. \personal\docs\*.*), so that should do the trick for portable usage.

tripex
Posts: 16
Joined: Tue Aug 08, 2006 10:51 pm

#36 Post by tripex » Sun May 06, 2007 12:25 pm

Andrew Lee wrote:We all know that file associations and shell extensions are not portable.
I have replied to someones comments. My intention wasn't starting a discussion about portability/stealth but giving info to him, because it seemed not clear to him, what you assume everybody knows. Have you removed my comment?
Andrew Lee wrote:For example, portable program launchers are pretty much useless without support for relative paths.
In my opinion that's not a good argue. According this logic you can also argue, the most CD burner, DVD ripper, overclocker, password hacker or system improving utilities at all are not working without installing a driver, hence they count as portable.
Andrew Lee wrote:...for some apps (eg. program launchers, MP3 players), it is clear-cut that relative path support is important for portability, but for other apps, it is less clear-cut.
Personally I don't like this discretionary stuff. Some people care more some less about whatever so in my opinion it's the best to make it clear and not to assume too much.

cmmehl
Posts: 128
Joined: Sun Feb 19, 2006 7:26 am

#37 Post by cmmehl » Sun May 06, 2007 8:22 pm

Andrew Lee wrote:cmmehl, regarding your comment about Save2ftp, the app indeed does not support relative paths (eg. ..\..\docs\*.*), but it does support absolute paths without drive letters (eg. \personal\docs\*.*), so that should do the trick for portable usage.
You're right, Andrew, this does the trick, thx for that - quite a handy app. But a pain to configure with this syntax ... it's worse than maths to get to the right statement for the path of the item to back up :twisted:

Would sure be easier if absolute relative paths were supported, or if there was a variable for the root.

Cheers
Chris

User avatar
Andrew Lee
Posts: 2212
Joined: Sat Feb 04, 2006 9:19 am
Contact:

#38 Post by Andrew Lee » Mon May 07, 2007 5:43 am

I have replied to someones comments. My intention wasn't starting a discussion about portability/stealth but giving info to him, because it seemed not clear to him, what you assume everybody knows. Have you removed my comment?
My apologies. I thought it was another discussion about portability of apps, which I tried to direct to this thread. I have added the comment back. It would be clearer if you indicate who you are directly your reply to (in this case, "ken").
In my opinion that's not a good argue. According this logic you can also argue, the most CD burner, DVD ripper, overclocker, password hacker or system improving utilities at all are not working without installing a driver, hence they count as portable.
Not sure I understand your statement. Could you please elaborate? If the proggie requires manual installation of driver, then it is not portable. But if the app installs a driver dynamically (and remove it upon exit), then it should be portable.
Personally I don't like this discretionary stuff. Some people care more some less about whatever so in my opinion it's the best to make it clear and not to assume too much.
In that case, we can agree to disagree, and leave it at that. I would rather the site remains useful to me, rather than follow some black-and-white rule and choke all the life out of it.

User avatar
Andrew Lee
Posts: 2212
Joined: Sat Feb 04, 2006 9:19 am
Contact:

#39 Post by Andrew Lee » Mon May 07, 2007 5:45 am

But a pain to configure with this syntax ... it's worse than maths to get to the right statement for the path of the item to back up
I would have thought most people will find this syntax easier (since you just omit the drive letter). Relative path is a lot harder, since you must master the mental arithmetic of navigating the folder tree and converting them into relative path syntax!

cmmehl
Posts: 128
Joined: Sun Feb 19, 2006 7:26 am

#40 Post by cmmehl » Mon May 07, 2007 7:19 am

Andrew Lee wrote:I would have thought most people will find this syntax easier (since you just omit the drive letter). Relative path is a lot harder, since you must master the mental arithmetic of navigating the folder tree and converting them into relative path syntax!
Yep, you're right. Actually, the app can do both, relative and direct path without drive-letter. I had tried the first one first with its "mental arithmetic" >g< and that's what I had referred to.
Andrew Lee wrote:I would rather the site remains useful to me, rather than follow some black-and-white rule and choke all the life out of it
Absolutely! And the site has proven to be useful not only to you, but to uncounted numbers of faithful users, too. I just love it :-)

Cheers
Chris

tripex
Posts: 16
Joined: Tue Aug 08, 2006 10:51 pm

#41 Post by tripex » Mon May 07, 2007 1:46 pm

Andrew Lee wrote:It would be clearer if you indicate who you are directly your reply to...
OK, my mistake.
Andrew Lee wrote:drivers
It's not only about drivers but everything that changes the host more dramatically than only the system MRU. I believe there are applications, that have to change the host to work properly regardless how much effort the author puts in to make it portable. You argue an mp3-player w/o a usable MRU would be useless, so you start to ALLOW these kind of applications special allowances. With exactly the same argument you could allow file associations, couldn't you? But they have a much more impact. And finally you allow anything, which is necessary for the purpose of an application. Obviously you wouldn't, because of your personal judgement of appropriateness. And that's the issue. Many people like me don't know your level which desides between thumb up or thump down. And because of this you will always encounter purist comments. You can delete them, you can ignore them, you can try to turn purists to free-lovers in discussions or you can specify your goals of the/your site clearer which would either leads to grading or a statement like this:
Andrew Lee wrote:I would rather the site remains useful to me, rather than follow some black-and-white rule and choke all the life out of it.
Grading is not necessarily choking.

Anyway, I will step back from the discussion because it seems there is nothing more to say for me.

CU
Andy

Kermode
Posts: 135
Joined: Fri Apr 14, 2006 5:59 am

#42 Post by Kermode » Sat May 12, 2007 4:25 pm

Portable means you can zip the folder on one machine, unzip it on another and it runs there without you setting a lot of stuff up.

Screw the rest :)

calm_observer
Posts: 47
Joined: Tue Mar 27, 2007 12:21 pm

#43 Post by calm_observer » Sun May 13, 2007 12:30 pm

Andrew Lee wrote:...Are we asking the author of Irfanview to figure out a way to do file associations and shell extensions portably (which technically can't be done)...
while i agree with most all of what you have posted, i am not sure i agree that file associations or for that matter shell extensions cannot be made portable. the real question to me at least, is do they need to be, and for my purposes they do not.

for example to make file extensions portable; on start up you need to save the current associations, install your new ones, and on shut down reinstall the original.

calm_observer
Posts: 47
Joined: Tue Mar 27, 2007 12:21 pm

#44 Post by calm_observer » Sun May 13, 2007 12:36 pm

Kermode wrote:Portable means you can zip the folder on one machine, unzip it on another and it runs there without you setting a lot of stuff up.

Screw the rest :)
ok, but what if you can automate "the setting a lot of stuff up". i think alot of apps that are not considered portable here can be made portable without alot of effort ~ just MHO based on experience :cool:

calm_observer
Posts: 47
Joined: Tue Mar 27, 2007 12:21 pm

#45 Post by calm_observer » Sun May 13, 2007 12:41 pm

tripex wrote:Is there any reasonable way to avoid this problem and keep using the MRU function? I don't think so...
you bet there is if you use a script to start the program, and another after the program has ended.

Post Reply