View Issue Details

IDProjectCategoryView StatusLast Update
0000649OpenMPT[All Projects] Feature Requestpublic2018-11-11 10:55
ReporterharbingerAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Platformx86OSWindowsOS VersionXP
Product VersionOpenMPT 1.24.02.00 / libopenmpt 0.2-beta10 (upgrade first) 
Target VersionOpenMPT 1.?? (long term goals)Fixed in Version 
Summary0000649: Re-register MPT instantly
Description

Occasionally my registry will sometimes lose track of openMPT, and I can no longer double-click on an MPTM file and have it open automatically by the latest version I have installed. Maybe in the Help menu, we could have a selection to re-apply the registry settings for the latest version of the installed openMPT with a simple mouseclick.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Relationships

related to 0001011 new Automatic update 
related to 0001123 new Provide unified multi-arch installer 

Activities

goluigi

goluigi

2015-03-10 23:03

reporter   ~0001977

wait, but wouldn't this be a problem with your registry more than openmpt? (haha idk)

Saga Musix

Saga Musix

2015-03-10 23:55

administrator   ~0001978

Well yeah, if something like this happens (and you don't have other programs fighting for the same extension), I'd be worried about that computer. Anyway, registry problem or not, it's still a valid request for people who don't like using the installer, and I originally intended to implement this in 0000607 actually, but I haven't gotten around doing so (also since it would require me to look into UAC...).

Saga Musix

Saga Musix

2018-09-10 20:44

administrator   ~0003620

cc @manx

Since it would be a lot of duplicate work to keep file associations alive in the installer and settings dialog at the same time, we'd of course want to remove those settings in the installer.
However, now we need to consider when to apply these registry settings: Doing so on every startup or every version update (unless in portable mode) might be desirable, in particular since upgrading to a new version may require new registry settings to be written (like when upgrading to 1.28 we need to remove the DDE keys and add the /shared parameter).

In summary, the registry should be updated whenever

  • the user hits the "Apply" button in the settings dialog
  • OpenMPT was updated to a different version or
  • every time OpenMPT is launched (debatable)

Naturally we would only write to the registry if any changes are detected or needed:

  • The OpenMPTFile executable points to a different path (on startup when not in portable mode and when using the settings dialog)
  • The user changes the selection of associated formats (only in the settings dialog)

Three more things to consider:

  1. Even in portable mode, changes done through the settings dialog should probably be applied, at the very least to remove any existing associations.
  2. OpenMPT advertises itself to Windows which file extensions it can open, which is different from the actual program used to open a specific file extension. It is desirable to not remove this information from the registry when the user un-registers all file extensions, but maybe we need a separate button to completely un-register this information as well.
  3. The uninstaller will still need to be able to erase all these registry settings.
manx

manx

2018-09-12 06:12

administrator   ~0003621

I do not think we should ever write file associations to the registry on every program start, because this action requires UAC in the general case, which, I think, should only get triggered after explicit user action.
This immediately poses the question about what to do when OpenMPT got updated and actually needs to change these registry settings. I do not have any answer for this situation right now.

Portable mode should IMHO very much not touch registry, not even to remove settings left over by a non-portable install. I think the best solution here is to not even provide a file association configuration dialog in portable mode at all.

Regarding supported file type versus actual active file associations, I am currently not familiar enough with that mater to have any really qualified opinion here. Reading over https://docs.microsoft.com/en-us/windows/desktop/shell/how-to-register-a-file-type-for-a-new-application https://docs.microsoft.com/en-us/windows/desktop/shell/vista-managing-defaults https://blogs.windows.com/windowsexperience/2015/05/20/announcing-windows-10-insider-preview-build-10122-for-pcs/ , I am not even sure anymore that a configuration dialog actually makes even sense at all for modern Windows versions, and the correct approach might even be to just register everything in the installer and let Windows handle per-user file association via the provided UI and mechanism.

Another question is how (or if at all) we want to handle parallel install of OpenMPT variants (x86 vs amd64).

In any case, as there is pretty much every detail here still up for discussion and undecided, I think all of this will be OpenMPT 1.29 and not 1.28.

manx

manx

2018-09-12 06:15

administrator   ~0003622

Also, if a Windows installation randomly loses registry settings like file associations, there is something severely wrong with that particular Windows installation. I do not think working around such system problems should be of any concern for deciding how OpenMPT handles file associations.

manx

manx

2018-09-12 07:25

administrator   ~0003623

I think we should focus on what would be suitable for Windows 10, and basically ignore older platforms for designing how to handle file associations in the future. In particular, iff a dialog for enabling/disabling individual file associations does not make much sense in Windows 10 from an UX guidelines perspective, I do not think we should by now start implementing one, even if it would make more sense on Windows XP or Windows 7.

StarWolf3000

StarWolf3000

2018-09-12 07:27

reporter   ~0003624

UAC shouldn't trigger, if the file association is done at HKCU (HKEY_CURRENT_USER) instead of HKLM (HKEY_LOCAL_MACHINE). HKCU registers your file types for your current logged-in user only, which doesn't matter, if you're the only one using it. HKLM requires Admin privileges, but registers them on the global level for all users.

Windows losing registry data can be an effect of a dying hdd or some cleanup tools are running.

Regarding 32-bit and 64-bit installed side-by-side, I for myself have not any of the file associations enabled, but I created shortcuts in the "Send to" menu, so I can open modules with the version I want.

It can be a small dialogue, that asks "Re-register all known module file types with this OpenMPT version?", a checkbox for "Apply for all users (requires Admin privileges)?" and two buttons "Yes" and "No".

manx

manx

2018-09-12 07:56

administrator   ~0003625

If OpenMPT is installed system-wide, it also must register file extensions system-wide. That's the whole point of system-wide installation on multi-user systems. Thus we need to write to HKLM.

If the whole functionality of such a dialog would be to just re-register all file types, there is really no point in having it in the OpenMPT GUI. That's what a "repair" mechanism of installers is designed for in Windows. In particular, just re-installing OpenMPT would fix it.

The more I think about it, the more I think this should be kept in the installer. I think for Windows 10, it even makes most sense to unconditionally register all file types in the installer. The per-user file association handling of Windows 10 will take care for the rest (and we cannot and should not override that anyway).

I still have to properly and thoroughly read up on the precise inner workings of file associations in different Windows versions though. Thus, please still take my opinions with some grain of salt.

Saga Musix

Saga Musix

2018-09-12 18:13

administrator   ~0003626

In particular, iff a dialog for enabling/disabling individual file associations does not make much sense in Windows 10 from an UX guidelines perspective, I do not think we should by now start implementing one

From my experience with Windows 10, this is not the case. The most important registry entries are the ones that declare a program's capabilities to open certain files, that is true. But on top of that the program still has to be registered as the default to handle those file types, and this is what the UI would be doing. OpenMPT supports around 50 extensions, and I don't think we should leave the user alone in manually assigning all of them.

I do not think we should ever write file associations to the registry on every program start, because this action requires UAC in the general case, which, I think, should only get triggered after explicit user action.

This should of course only be done for current user file associations, if at all.

manx

manx

2018-09-12 19:05

administrator   ~0003627

Last edited: 2018-09-12 19:06

View 2 revisions

From my experience with Windows 10, this is not the case. The most important registry entries are the ones that declare a program's capabilities to open certain files, that is true. But on top of that the program still has to be registered as the default to handle those file types, and this is what the UI would be doing.

As far as I understand it (I have not yet tested this), an installer could either write to the system-wide HKLM\Software\Classes or the per-user HKCU\Software\Classes. HKCR is a view into the combination of both, with per-user taking precedence. From that follows, that, in the former case, setting these association will not actually override the associations for the current user, and in the latter case, associations will actually be different for the user that has installed the software compared to other users on the system. Neither outcome does make a lot of sense IMO.

Writing to HKCR (which we are currently doing) is not recommended and the outcome is not even specified, as far as I can tell.

I do not think we should ever write file associations to the registry on every program start, because this action requires UAC in the general case, which, I think, should only get triggered after explicit user action.
OpenMPT supports around 50 extensions, and I don't think we should leave the user alone in manually assigning all of them.

Windows 10 will display an association dialog the first time any particular file extension is invoked. It might make sense to allow the dialog to write to HKCU\Software\Classes, i.e. overriding the associations for the current user. I'm still not convinced that this dialog is desirable in Windows 10. The ProgID should probably be written to HKLM\Sofware\Classes by the installer.

As far as I understand it, the UX goal that Microsoft is trying to achieve in Windows 10 here, is, that an installer should NOT override any file associations.

manx

manx

2018-09-12 19:08

administrator   ~0003628

It might also make sense to look into thew 7-zip source code, which provides a file association dialog which even distinguishes between system-wide and per-user settings. However, in my experience it is rather confusing to use.

manx

manx

2018-09-12 19:17

administrator   ~0003629

Summarizing a bit:

Installer:

  • HKLM\Software\Classes\ProgID
  • HKLM\Software\Classes\Applications
  • HKLM\Software\Clients[...]\Capabilities\
  • maybe HKLM\Sofware\Classes\per-extension-defaults

Dialog:

  • HKCU\Software\Classes\per-extension-defaults

which in the end would avoid the need to required UAC for writing to HKLM after an OpenMPT upgrade supporting more file types, because these settings would be written by the installer.

manx

manx

2018-09-12 19:23

administrator   ~0003630

Also note that https://docs.microsoft.com/en-us/windows/desktop/shell/fa-file-types#deleting-registry-information-during-uninstallation tells to not remove the individual associations on uninstall. As far as I can tell, we currently delete these values on uninstall, which is very likely the wrong thing to do.

harbinger

harbinger

2018-10-15 15:37

reporter   ~0003665

Any progress on this issue?

Keep in mind, along with the other issues you pointed to, the main reason i myself was encountering this problem was if i moved the openMPT folder (like say from my "Music" directory to the "Music Creation" folder). Re-registering would save me from having to re-install open MPT (or search the registry and update everything manually).

manx

manx

2018-10-16 07:08

administrator   ~0003671

Well, we are still not at all sure whether such a feature in general would be: desirable, recommended, recommended against, useful in standard workflow behaviour, or even actively harmful to the installation and usage process of OpenMPT.

In general, moving/renaming installation folders of installed programs is not supported, neither by Windows, nor by other Windows Desktop applications, nor by OpenMPT. I do not think adding a feature explicitly targeted to this situation to OpenMPT would be useful, because it would special case OpenMPT compared to any other Windows Desktop applications. In particular, moving the installation folder will (in addition to file associations) also break uninstallation, which is handled not by OpenMPT directly but by the InnoSetup installation utility that OpenMPT uses.

In your particular situation, the recommended way to move the installation folder would be to uninstall and then reinstall OpenMPT.
Just re-installing OpenMPT over the moved-to location should, I think, also work, however I am not 100% sure that this will not confuse InnoSetup, and in particular any behaviour or issue concerning InnoSetup in this situation is outside of the scope that OpenMPT itself could handle or fix.

harbinger

harbinger

2018-10-22 17:06

reporter   ~0003679

That solution is definitely anti-intuitive and not user-friendly. One should be able to just move or rename any given folder based on the current situation. (Having cut my teeth on Mac computers, there was no such thing as a registry so we were able to move folders without a problem, unless of course you had an "alias" to the program, which would have to be re-linked.)

I know what you're saying will prevent/solve the problem, but i'm speaking in philosopshical terms. Unin-/reinstalling applications just so could have your folder called something else (or located somewhere else on your drive) is a superfluous workaround that i think a simple re-registering would solve — if in fact it can be programmed. Maybe a separate "use-at-your-own-risk" batch file would be a better solution than tweaking openMPT in this way.

manx

manx

2018-10-22 17:26

administrator   ~0003682

One should be able to just move or rename any given folder based on the current situation. (Having cut my teeth on Mac computers, there was no such thing as a registry so we were able to move folders without a problem, unless of course you had an "alias" to the program, which would have to be re-linked.)

This is not how Windows works or ever has worked. You need to complain to Microsoft.

OpenMPT will not implement a partial (and partial by necessity because we have no control over the uninstaller information stored by the installer) solution solely for a fundamentally unsupported and even unsupportable situation.

manx

manx

2018-11-11 10:54

administrator   ~0003709

https://docs.microsoft.com/en-us/windows/desktop/shell/default-programs

manx

manx

2018-11-11 10:55

administrator   ~0003710

https://blogs.msdn.microsoft.com/oldnewthing/20181016-00/?p=99985

Issue History

Date Modified Username Field Change
2015-03-03 02:49 harbinger New Issue
2015-03-10 23:03 goluigi Note Added: 0001977
2015-03-10 23:55 Saga Musix Note Added: 0001978
2018-09-10 20:44 Saga Musix Note Added: 0003620
2018-09-12 06:12 manx Note Added: 0003621
2018-09-12 06:12 manx Relationship added related to 0001011
2018-09-12 06:12 manx Relationship added related to 0001123
2018-09-12 06:15 manx Note Added: 0003622
2018-09-12 06:15 manx Target Version => OpenMPT 1.?? (long term goals)
2018-09-12 07:25 manx Note Added: 0003623
2018-09-12 07:27 StarWolf3000 Note Added: 0003624
2018-09-12 07:56 manx Note Added: 0003625
2018-09-12 18:13 Saga Musix Note Added: 0003626
2018-09-12 19:05 manx Note Added: 0003627
2018-09-12 19:06 manx Note Edited: 0003627 View Revisions
2018-09-12 19:08 manx Note Added: 0003628
2018-09-12 19:17 manx Note Added: 0003629
2018-09-12 19:23 manx Note Added: 0003630
2018-10-15 15:37 harbinger Note Added: 0003665
2018-10-16 07:08 manx Note Added: 0003671
2018-10-22 17:06 harbinger Note Added: 0003679
2018-10-22 17:26 manx Note Added: 0003682
2018-11-11 10:54 manx Note Added: 0003709
2018-11-11 10:55 manx Note Added: 0003710