The program adds itself to the registry key "OpenWithList" (under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Explorer\FileExts\.extension\OpenWithList ) for every image format opened.
For more detailed informations regarding the meaning of this registry key please read in the Microsoft article How to Remove Programs from the "Open With" List. Therefore the recommendation in the documentation under
Keys and values to ignore regarding the key "Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts" is definitely wrong and should be removed.
For the case that someone already use PhotoFiltre Portable it is necessary, that you manually remove the appropriate entries from the registry key OpenWithList (right click on the entry and select "Delete" from the context menu). You can find an illustrated instruction in the german Microsoft article under the section Einen Eintrag löschen.
Here now the necessary code, which must added in the section [RegistryKeys] into the file PhotoFiltrePortable.ini:
[RegistryKeys] OpenWithList=HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts
Finally, the download link for the revised version: PhotoFiltrePortable_7.1.0_Rev1.paf.exe
Download Size: 5,60 MB
MD5: ba9375f8603f15c3eef204063e6ee57a
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
You're backing up the whole FileExts key hierarchy, which is a no-no. If two apps did this, it would result in killing the existing values if you start them 1-2 and then close them 1-2.
Sometimes, the impossible can become possible, if you're awesome!
This case will only occur during the simultaneous start of two portable apps, whereas both apps use the same following code in the section [RegistryKeys]:
Surely you want to point out on that fact or?
When you start app 1, the existing values are backed up. When you start app 2, it's backed up again. If you then close app 1, it restores from backup. When you close app 2, all values are wiped out.
As policy, registry keys that are shared by multiple apps may not be backed up.
Sometimes, the impossible can become possible, if you're awesome!
Does it mean, that app2 wipes out all values of the registry key FileExts? And why app2 not restores from its own backup and instead wipes out all values?
App 1 backs up the key and replaces it with what is in the .reg file, which will be BLANK. App 2 then backs up the blank hierarchy when it starts. App 1 exits and restores the proper keys. Then App 2 exits and restores the blank ones it backs up.
So, do not use RegistryKeys for values shared by apps. It is designed for use by keys used by a single app. That's also why you're supposed to use it for HKCU/Software/Publisher/AppName but NOT for HKCU/Software/Publisher.
Sometimes, the impossible can become possible, if you're awesome!
I have now understand your argumentation. Therefore I'll try to find a better solution. But as I mentioned above, this scenario assumes that app2 starts additionally and simultaneously alongside app1.
They don't have to start at the same time. Just ANYTIME the other app is running. Running multiple apps is common and an everyday occurrence. I have 6 apps open right now (in addition to 6 background apps). I'm well aware of the situation that can happen, this is why handling shared keys using [RegistryKeys] is specifically forbidden.
Sometimes, the impossible can become possible, if you're awesome!
Unfortunately I've formulated me improperly. But I want express exactly that, what you've mentioned in your last post.
In the moment I have a new idea by using a custom code. But it seems to be more difficult. Can you tell me, how is the exact name of the backup and where will it stores?
These registry entries are automatically generated by Windows for all programs, this isn't an issue with PhotoFiltre so cannot be considered a bug.
On my own system the following PortableApps show up in the first 10 FileExts entries: Dia, WinMerge, 7zip, WxDevC++ (dev test).
There is no "right" way to handle these keys from a portable viewpoint:
Basically it should be noted, that the creation of registry entries stands in clear contradiction to the defintion of a portable program. In so far it is completely irrelevant, that these entries are automatically created by Windows. Even the recognized website Portablefreeware.com reported this bug in PhotoFiltre.
Below I would like to make some comments on your 3 bullet points.
With the above mentioned code (I'll repeat it below) you wouldn't lose all "Open With" data that would populate between the app starting and closing.
Precisely because nobody can tell exactly what extensions a user will open with an app, I've decided for a backup of the complete registry key FileExts.
I'm thoroughly convinced, that it is possible with custom code to solve this problem. Moreover, this custom code required under the above-mentioned problems by John mandatory.
Suppose the portable programs app1, app2, ... appn will be launched sequentially in the order, in which they are consecutively numbered. Furthermore all these apps should use the same code, which I described under "Remarks to your 1. bullet point". The main question is now, how can I solve the problem, which John mentioned?
Let me name suitable the backups of the portable programms app1, app2, ... appn as backup_app1.reg, backup_app2.reg, ... backup_appn.reg. Since app1 was started at first, it would be necessary in a first step, that the backup with the specific name "backup_app1.reg" will be copied to a separate folder. Afterwards this copied backup must renamed in a neutral name. In our case we call this renamed backup "FileExts.reg" aptly.
Now starts the next app2 and create the blank file backup_app2.reg in a folder, whereas we call this folder suitable "Backup_app2". Then the file backup_app2.reg will be renamed into backup_app2_old.reg. Afterwards the file "FileExts.reg" will be copied in the folder "Backup_app2". Finally the file "FileExts.reg" will be renamed into backup_app2.reg.
All the above described steps must be coded properly.
As already explained, you can not backup/restore shared keys like FileExts. I already laid out the process by which data loss will occur. Any app that attempts to backup/restore a shared key like this will not be approved for release due to the high likelihood of data loss.
Sometimes, the impossible can become possible, if you're awesome!
But have you read all my explanations under the above No. 3? There I have described a possible solution for your problem. Therefore please tell me the exact name of the backups and where it stores.
Check the PortableApp Guidelines. Pleas take note of the point where it specifically states
These entries are automatically generated by Windows, therefore they are acceptable in John's own guidelines.
1. Yes you will lose data between opening and closing the app. The app will take a backup on launch, then you leave the app open for an hour. While the entries added in that hour will not be affected, deleted entries would appear again and the value of FileExts\.<insert extension here>\OpenWithList\MRUList will be overwritten when the app restores the backed up keys.
3. There is no way to do it without the possibility of still losing data as in point 1. There is still the section of time between the last backup and your restoration of the keys in which you will lose data, even if you could get your sequential backup idea to work.
Personally I am of the opinion that any defintion and so of course also the cited by you must eventually be revised. Nothing in this world is created for eternity!!! And what do you say regarding the objections on the cited website Portablefreeware.com? Obviously it would be arrogant, if you ignore all these objections, because on this website participate also high qualified programmers.
Regarding your objections under No. 1 and 3 you have right. Accordingly I'll now look after another way to solve the problem.
I agree that any definition is open to revision. I do not agree that it must eventually be revised, as definitions are based on opinions which can differ from one person to another, and may or may not change over time.
For the purpose of a portable application your opinion of what is portable may be different to John's may be different to my own, and that is fine. For the purpose of a PortableApp, John's definition is the rule by which we measure them all.
Because this discussion now has been developed in a polemical direction, I want to finish it at this point.
winterblood wrote ...
Let me analyze your objection in respect of the loss of data in connection with the following situation. Suppose there exist an app, which can run simultaneously in multiple instances. We will call this app suitable "multiple_instances". Furthermore we assume, that this app stores its settings in the registry key HKCU\Software\Publisher\multiple_instances. To make this app portable, you would certainly use the following code:
The portable version of the app will take a backup on launch, then you leave the app open for a hour. During this hour you launch now the locally installed version of the app and you make some alterations in the settings. After the restoration of the registry key via the portable version of the app you will lose all the altered settings of the locally installed version of the app. Accordingly your above recommendation to make the program portable would end into a deadlock.
That is why all apps default to SingleAppInstance=true. It is only changed in cases where the developer knows this won't occur.
PFC's definition of portable is not recognized beyond their site. They permit apps to leave folders, temp files, data files, registry keys, etc behind and have paths break for recently used files, last opened directory, graphic/sound themes, etc when you move PCs and still consider the app portable. They make notes under the "Stealth" (misnomer since there is no such thing as a stealth app) and path entries about this for affected apps.
Sometimes, the impossible can become possible, if you're awesome!