3
votes

I have a program that read and write registry files in order to remember window position etc. This is very simple when it comes to just being the administrator but not so much when you are just a user on the system.

I use advanced installer if you have any cool suggestions on that end.

  1. Where should register parameters be located in order for each user to use my application with their own registry values?
  2. Is that path general enough so the program can locate that folder without running into issues?

Edits/Updates:

Question 1: Where are you putting things if not in HKEY_CURRENT_USER?

Answer: When i put the files under HKEY_CURRENT_USER it would only place it under that user. So if I were to install the program as administrator, it would only be that user that has the files. As i'm using advanced installer, i'm unsure if that falls under some settings value.

Statement 1 from Bogdan Mitrache: If you prefer, you can also leverage the self healing support from Windows Installer (supported by Advanced Installer too) to have the installer write the default settings under HKCU for each user launching the app, even if installed by the administrator. Here is an example with files, but it applies for registry too: advancedinstaller.com/user-guide/qa-self-healing.html

Response: This is a good solution except for the issue that I have a conditional installation. The user can choose to install one or the other feature where both of them uses these registry values. This is probably why it is not working for me. I'm going to look over duplicating the files in a logical sense in AI.

1
Where are you putting things if not in HKEY_CURRENT_USER?molbdnilo
maybe you should use HKCU instead of HKLMFederico
When i put the files under HKEY_CURRENT_USER it would only place it under that user. So if I were to install the program as administrator, it would only be that user that has the files. As i'm using advanced installer, i'm unsure if that falls under some settings value.413X
Application settings (ie non-user specific) under HKLM, and user settings under HKCU. User settings should be set by the application on 1st run by each user not by the installer.Richard Critten
If you prefer, you can also leverage the self healing support from Windows Installer (supported by Advanced Installer too) to have the installer write the default settings under HKCU for each user launching the app, even if installed by the administrator. Here is an example with files, but it applies for registry too: advancedinstaller.com/user-guide/qa-self-healing.htmlBogdan Mitrache

1 Answers

1
votes

The correct way to handle this is to store default values (such as during installation) in HKEY_LOCAL_MACHINE (if at all), and then later store user-specific values in HKEY_CURRENT_USER.

When the app needs to read a value, check in HKEY_CURRENT_USER first, and if not found then check in HKEY_LOCAL_MACHINE (or use a hard-coded default).

When the app needs to store a value, store it only in HKEY_CURRENT_USER.

And yes, this does mean that if your app is being run by an admin, by default it is going to read the value from the admin's key, and store the value in the admin's key. And that is perfectly OK, because the admin is the user of the app at that time. If the app is being run by a non-admin, then the values will be relative to that user instead.

In a situation where the app is running as an admin user but needs to read/store a value in another user's HKEY_CURRENT_USER key (for instance, when a non-admin user is logged into Windows and the app is running with UAC elevation using another user's login), then the app can open the HKEY_CURRENT_USER key of the other user by either:

  • impersonating the other user and then using RegOpenCurrentUser().

  • load the other user's profile by using LoadUserProfile(), which returns a handle to the loaded user's HKEY_CURRENT_KEY key (amongst other things).

If you want to access another user's HKEY_CLASSES_ROOT key instead of HKEY_CURRENT_USER, you can use RegOpenUserClassesRoot().