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

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...).

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.

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.

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.

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.

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".

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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

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

https://docs.microsoft.com/en-us/windows/compatibility/file-type-and-protocol-associations-model

https://channel9.msdn.com/Events/Build/BUILD2011/PLAT-282T (mostly metro-specific, but also shows the intended user experience, which also applies to desktop applications)

https://docs.microsoft.com/en-us/windows/win32/shell/app-registration

r12991 / 1.30.00.04