Registry keys are created in per-user HKCU instead of system-wide HKLM

changed weight to 5

changed milestone to %6.10.1

Hmm, HKLM looks like it contains a different hierarchy.

Is HKEY_USERS/.DEFAULT what we want?

Neil, do you know what we should be doing here?

This kind of decision (user vs system install) should be controllable during installation. Also, registry modification ought to be optional, like anything the installer does (cf. #2505 (closed)).

mentioned in issue #2510 (closed)

The bug is related to #2510 (closed) - the modification of system environment (namely of PATH) suffers from the same problems as registry modification.

You can put keys in either HKLM (local to the machine) or HKCU (local to the current user). I think for some purposes they get unioned together. Often Windows app's offer to install either globally or locally, so this is something we could provide. However, in some cases, we need admin access to do HKLM which is why we picked HKCU - partly this is because me and Duncan don't have admin access on our work machines.

As for Claus's comment that you should be able to stop it, this doesn't seem to offer many benefits, and isn't something that is done by any other installers. What would be the use case?

Trac metadata

Trac field	Value
Type	Bug → FeatureRequest
Operating system	Unknown → Windows

HKLM and HKCU are completely separate registry subtrees. HKCU/Software and HKLM/Software never get unioned together. HKLM is always read only for non-admins, just like /etc/ on Unix, not "in some cases".

Applications not just "often" offer both per-user and per-machine installations - it's an industrial standard, a commonly agreed good practice, described in MSDN. Moreover, if a program doesn't support to choose between per-user and per-machine installation, it is assumed that the program will be installed per-machine. So if GHC installs per-user, it should notify about such unusual and unexpected behaviour using big red letters. The lack of such notification is definitely a bug, the lack of per-machine installation is a feature.

What do you mean by "isn't done by any other installers?" You can hardly find a program without a possbility to install per-machine. The registry modification is never optional, but the environment modification is optional in any decent installer. Quality installers do support a choice between per-machine and per-usual installation, there is even a de facto standard for the dialog, and there are such things as administrative installation, silent installation, domain-wide GPO installation, advertisement, which is a good idea to support.

I don't see the use case for optional registry modification, but I do for optional environment modification and per machine installations. Which use case did you want to see?

I am sure some API for registry will use HKCU in preference and fall back to HKLM - although I can't remember which API, or even which language - that is all I meant by unioned.

I am quite happy to believe that having options to install per user and per machine is good, and my reclassification as "feature" rather than "bug" was intended to indicate that what is there currently works, but some people want more - not that what you want is unreasonable. However, since it really actually doesn't matter, I've changed it back to bug :-)

With the final comment, asking for a use case, or other installers, I was referring only to Claus's suggestion of having an optional "put nothing in the registry".

In summary I think I agree with you 100% but am not sure about the extra bit of "don't touch my registry" that Claus wanted. However, if there is a use case, its easy enough to add in.

Trac metadata

Trac field	Value
Type	FeatureRequest → Bug

Replying to [ticket:2489#comment:25232 NeilMitchell]:

In summary I think I agree with you 100% but am not sure about the extra bit of "don't touch my registry" that Claus wanted. However, if there is a use case, its easy enough to add in.

My "use case" is simply that installers are terribly easy to get wrong, and even if they do things right, they often regress later, or they do not cooperate with other Haskell installers, simply because making them is a job nobody wants (which is why I appreciate Sigbjorn's and your efforts in this area). I have been bitten so often by this in Haskell land, and in so many different ways (#916 (closed) has a very small selection of examples), that I switched to using binary snapshots instead of installers; and now I automatically ask for everything to be optional, so I can switch off anything I don't like!-)

If we get our daily binary snapshots back, and you address the individual installer actions as options, including #2505 (closed), and the ghc installer agrees with any upcoming Haskell Platform installer (and you are probably also in a good position to coordinate with Neil on WinHugs, #916 (closed);-), then there is probably no real need for a separate "just unpack my binary" installer. But if your installer does not support this option, chances are it has built-in assumptions that will bite me later; so consider it a quality measure rather than a use case!-)

nimnul: I remembered why I was thinking of unioned bits of registries. To compute file type associations, Windows looks in both HKCU and HKLM.

claus: That does sound like a sensible use case, so the option does deserve to be added.

I'm not going to be even looking at the GHC installer issues for months at least, but I've listed the ones I will tackle in this bug: http://code.google.com/p/ndmitchell/issues/detail?id=55. If anyone wants to shut any of those bugs before I get to them, I'm perfectly happy!

Perhaps what Claus is thinking of is a Portable GHC package, one that doesn't modify the registry. An increasing number of software packages have a so-called Portable version that allows installation to a USB flash disk. Something along those lines for GHC might be useful.

There is no such thing as "installer that doesn't modify the registry". Any installer at least creates that "uninstall me" entry, and MSI installers modify much more. Installers are a poor choice for portable packages - a classic "binary tarball" package is much better for that purpose. For example, if you install something to a removable disk, and move the disk to another box, the registry won't go with you, and you'll be in trouble.

More reasons to have tarballs (or 7z/tbz/whatever) are to allow installations to a company-wide network drive, and to allow GHC to survive OS re-installation.

It's a pity that GHC installer is not an MSI installer - MSI is more robust than other installers, and is better fit for corporate use (see the list of MSI features in my earlier post - I mistakenly thought that "Windows Installer" label at http://haskell.org/ghc/download_ghc_683.html meant "Microsoft Installer")

MSI has an API to query installation location for a package, without a need to know whether it is system-wide or per-user:

Here is .js code, but of course Microsoft has plain C api for that too.

var i = WScript.CreateObject("WindowsInstaller.Installer")

var p = i.products

for (var j = 0; j < p.Count ; j++)
{
	WScript.Echo(i.ProductInfo(p.Item(j), 'ProductName'));
	WScript.Echo(i.ProductInfo(p.Item(j), 'VersionString'));
       	WScript.Echo(i.ProductInfo(p.Item(j), 'InstallLocation'));
}

Of course I understand that migrating to WiX/MSI is not an option in observable future, but that would save us from lots of problems.

nimnul: An MSI would be the best option, but it requires someone who knows all about MSI's. I did look into WiX but didn't have the time to get anything to a useable level.

If someone with the necessary expertise to do the .msi solution, and the time to keep it working, then that would be great!

Trac metadata

Trac field	Value
Architecture	Unknown → Unknown/Multiple

changed milestone to %6.12 branch

changed milestone to %6.12.1

removed milestone

Trac metadata

Trac field	Value
TypeOfFailure	- → OtherFailure

Trac field	Value
Version	6.8.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	None
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system	Unknown
Architecture	Unknown

Registry keys are created in per-user HKCU instead of system-wide HKLM

Child items 0

Activity