If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

By default CWinApp::SetRegistryKey() set the application registry under HKEY_CURRENT_USER so each user (windows login account) has their private settings stored for them. However I would like my applications settings to be common for all windows users so I want to store them under HKEY_LOCAL_MACHINE.

Can I do this use MFC registry functions? I hope I don't have to discard the MFC registry access functions in favor of independent registry calls to accomplish this!

SetRegistryKey was designed to store read/write user specific data, so that's why HKCU was chosen. You can step into the SetRegistryKey call and look at the appui3.cpp file in the mfc sources. You'll see it's hardcoded to use HKCU.

If you want different behavior, you'll need to roll your own, but keep in mind that on the newer OS's, apps won't have access to HKLM by default, so your app will need to run under higher access privileges.

By default CWinApp::SetRegistryKey() set the application registry under HKEY_CURRENT_USER so each user (windows login account) has their private settings stored for them. However I would like my applications settings to be common for all windows users so I want to store them under HKEY_LOCAL_MACHINE.

HKEY_LOCAL_MACHINE was designed to be used as read-only for normal users. So you could write some initial data to it while installing your application; then all users would be able to read those data.
To write to HKLM as Arjay pointed out the users have to run under higher access privileges, which nowaday almost impossible (except some cases like software installing.)

SetRegistryKey was designed to store read/write user specific data, so that's why HKCU was chosen. You can step into the SetRegistryKey call and look at the appui3.cpp file in the mfc sources. You'll see it's hardcoded to use HKCU.

If you want different behavior, you'll need to roll your own, but keep in mind that on the newer OS's, apps won't have access to HKLM by default, so your app will need to run under higher access privileges.

That's a good idea but string thing is that it nevers allow me to step into SetRegistryKey() function so I can't get to its source otherwise I thought I could use function cloning here.

I am using VS2010 and I 'step in' at this line with debugger it just do 'step over'. I was surprised too by this behavior. Thanks for the code but I don't really see the harcoded value for HKEY_CURRENT_USER. I see another thing though which I also wanted to fix. The default registry entry is the executable name which I wanted to be fixed so I see I could fix that too by cloning this function. However how I direct this to HKEY_LOCAL_MACHINE or anywhere else that I don't have to run into permission issues?

I am using VS2010 and I 'step in' at this line with debugger it just do 'step over'. I was surprised too by this behavior. Thanks for the code but I don't really see the harcoded value for HKEY_CURRENT_USER. I see another thing though which I also wanted to fix. The default registry entry is the executable name which I wanted to be fixed so I see I could fix that too by cloning this function. However how I direct this to HKEY_LOCAL_MACHINE or anywhere else that I don't have to run into permission issues?

You have to open the appui3.cpp file to see it. Order to do this, you needed to install the mfc sources when you installed VS. If you didn't, try searching the files in the VS install folder for CWinApp::SetRegistryKey.

As far as directing it to HKLM - you don't (I thought we explained this already???). And if you attempt to access HKLM from your program without the proper permissions, it will fail.

If you need read-only access to info for all users, then use 2kaud's suggestion from his earlier post.

You have to open the appui3.cpp file to see it. Order to do this, you needed to install the mfc sources when you installed VS. If you didn't, try searching the files in the VS install folder for CWinApp::SetRegistryKey.

As far as directing it to HKLM - you don't (I thought we explained this already???). And if you attempt to access HKLM from your program without the proper permissions, it will fail.

If you need read-only access to info for all users, then use 2kaud's suggestion from his earlier post.

Since you said its hardcoded to use HKCU, I just wanted to redirect it to HKLM and see what happens. I thought it would be interesting to try on XP (which are my users) but Windows 7 will definitely pose a problem with permission. I was just not able to see the hardcoded part but I will go with the other suggestion.

. . . I see I could fix that too by cloning this function. However how I direct this to HKEY_LOCAL_MACHINE or anywhere else that I don't have to run into permission issues?

Cloning Windows OS?

Okay, getting serious. You were told several times: once you get to writing to local machine hive you inevitably run into permission issue. Once you get to writing under system Program Files folder, you're in trouble again. That was done by Windows architects on purpose, and you have no other way but live with that. If your design contradicts to very basic Windows security guidelines, you're on your own and free to go wherever you want until (or unless) Windows stops you.

I don't know why would anybody need a multi-user app settings be kept in the same storage (.ini or registry or xml, whatever), but if you want to do that, just do that, but don't expect too much help from OS or MFC framework for unwelcomed things.

Since you said its hardcoded to use HKCU, I just wanted to redirect it to HKLM and see what happens.

If you change the file to point to HKLM and recompiled the MFC source files, the data would be redirected to HKLM. But then you would have to distribute the recompiled MFC dll with your app and that would violate MS's MFC redistributable agreement, not to mention break other apps that happened to use the modified DLL. On newer OS's you are also going to run into issues with the private copy and it may be flagged as spyware (because it's been modified). In short - you open up a big can of worms here just because you are attempting to do something that is non-standard and has been locked down by MS.

Originally Posted by zspirit

I thought it would be interesting to try on XP (which are my users) but Windows 7 will definitely pose a problem with permission. I was just not able to see the hardcoded part but I will go with the other suggestion.

If it were me, I would just would store an xml file in the shared location that was mentioned and use IXMLDocument interface to manipulate the xml. I would write a wrapper class to make it simple to access it from my class.