Installation inconsistency (Windows)

[w3lld0ne]

Currently, installer performs a machine-wide installation (requiring UAC elevation) but writes its uninstall entries to 'HKEY_CURRENT_USER' registry key, which may confuse some software like package managers (WinGet is one of them).

I believe for proper consistency you should either:

1. choose to install into user directory and leave HKCU as it is now (also disable UAC elevation in this case);
2. choose to install into ProgramFiles as it is now but use HKLM ('HKEY_LOCAL_MACHINE') for uninstall entries so that any admin on PC can uninstall the software, not only the one who installed it.

Also, some installers support both types of installation at the same time via command-line arguments like '/CURRENTUSER' and '/ALLUSERS'.

[SomberNight]

PRs welcome if you have time.

[w3lld0ne]

Hi @SomberNight, I can create a PR but I want to clarify something before I do that.
Which path do you prefer to go?

What I'd select is an option number 1 (fully user-based installation without UAC elevation), because I see it as the most logical choice for Electrum.
I may be missing something, but I 'patched' the official installer to not require elevation or admin account, and I was perfectly able to install Electrum into my user directory (at the same time I couldn't install to ProgramFiles anymore, access was denied for obvious reason). I've even tried to install & use Electrum under non-admin account and it was successful too. This was tested on Win10 22H2 & Win11 21H2 & Win11 22H2 VMs with UAC enabled.

So to sum up, does Electrum require admin rights only to be able to install into ProgramFiles by default? And are you okay with the choice to make user-based installation the preferred one instead?
-If yes, then it's an easy fix: just remove elevation requirement + change default installation dir from '$PROGRAMFILES\Electrum' to '$LOCALAPPDATA\Electrum'. Also please note that if user actually needs to install into ProgramFiles for any reason, nothing stops him from launching the installer as admin manually (he'd still receive registry entries in HKCU instead of HKLM, which may be undesired, but proper dynamic regpath selection is a job for custom command-line arguments, environment configuration, or a plugin*);
-If not, then we should probably stick to option number 2 (machine-wide installation as it is now, and all HKCU entries should be updated to HKLM, including URL protocols registration).

Either way, I'll be glad to create a PR.

* I've just found special NSIS plugin that allows user to choose how to install the app, we may integrate that instead of hardcoding the paths.

[SomberNight]

So to sum up, does Electrum require admin rights only to be able to install into ProgramFiles by default?

Yes, I think so.

What I'd select is an option number 1 (fully user-based installation without UAC elevation), because I see it as the most logical choice for Electrum.
-If yes, then it's an easy fix: just remove elevation requirement + change default installation dir from '$PROGRAMFILES\Electrum' to '$LOCALAPPDATA\Electrum'

This sounds good to me. However, I only have minimal familiarity with what the related current best practices are for Windows, and what other programs are doing (or indeed with these kind of windows internals in general).

---

One thing to consider is existing installs. What will happen if a user already has Electrum installed into $PROGRAMFILES, and they run the installer for a new version? I suppose we would leave the old version in $PROGRAMFILES to linger around? Maybe we could clean it up (although that would require a UAC prompt I guess). Or we would just mention it in the release notes... :/

---

What about URI-handlers?

electrum/contrib/build-wine/electrum.nsi

Lines 135 to 139 in 663ea43

	;Links bitcoin: and lightning: URIs to Electrum
	WriteRegStr HKCU "Software\Classes\bitcoin" "" "URL:bitcoin Protocol"
	WriteRegStr HKCU "Software\Classes\bitcoin" "URL Protocol" ""
	WriteRegStr HKCU "Software\Classes\bitcoin" "DefaultIcon" "$\"$INSTDIR\electrum.ico, 0$\""
	WriteRegStr HKCU "Software\Classes\bitcoin\shell\open\command" "" "$\"$INSTDIR\electrum-${PRODUCT_VERSION}.exe$\" $\"%1$\""

Can those "HKCU" registry keys be set without admin privileges?

[w3lld0ne]

This sounds good to me. However, I only have minimal familiarity with what the related current best practices are for Windows, and what other programs are doing (or indeed with these kind of windows internals in general).

I think per-user isolation is indeed the modern best practice. Take, for example, Google Chrome, Python-v3, or VS Code. All default to per-user installation (and support per-machine too if explicitly asked). Simple as that, different users may need different sets of software. Different users may use different wallets afterall.
One possible concern here is app size. Duplication of large apps (if more than one PC user needs them installed) may have negative impact on the users' disk space. But this should not be the case for Electrum as it's taking just around ~100MB.

What about URI-handlers? Can those "HKCU" registry keys be set without admin privileges?

Yes, no problem with that.

One thing to consider is existing installs. What will happen if a user already has Electrum installed into $PROGRAMFILES, and they run the installer for a new version? I suppose we would leave the old version in $PROGRAMFILES to linger around? Maybe we could clean it up (although that would require a UAC prompt I guess). Or we would just mention it in the release notes... :/

Previous installation path is kept in registry, and installer automatically presents it to user for easy update. Thus, for those who already have Electrum installed, elevation will still be required since they'll probably install in $PROGRAMFILES again. Or, if they decide to change the installation path, then previous instance will be left orphaned indeed and will need manual deletion of files (all registry entries, desktop & Start menu icons, URI-handlers will point to the new instance).

Well, indeed, update process is the main barrier here, as it just complicates things instead of simplification. I think this entire installation behaviour change (whatever it'd mean in the result) can be treated as a breaking change and be postponed to the next major version release, or until some ideal solution is found.