"Global" settings under Vista?
-
I've got an application written for Windows XP that I'm trying to get to run under Vista, and I'm having some issues related to UAC. I see several ways to tackle these problems, and I need some guidance on the "right" way to go about this. When our software runs for the first time, the user is prompted to enter a product key, which we store in the registry under HKEY_LOCAL_MACHINE\Software\<company name>\<program name>. Under Vista, this becomes virtualized, so that every user on the machine gets prompted for the key. Using the installer to put the key into the registry seems to avoid this problem, but this raises other issues. If we have the installer validate our product key, we'll need to build a DLL or script for the validation, and we're concerned about that being reverse-engineered/hacked. If the installer just puts the key in, and our software validates it when it runs, then we need to provide a mechanism for the user to correct a bad key, and we face registry virtualization again. We have a similar issue with some global settings which apply to all users, also stored in HKEY_LOCAL_MACHINE\Software\<company name>\<program name>. I can add a manifest to the program so that it has the privileges it needs to avoid virtualization, but then the user faces the wrath of UAC every time they run our program. There's also the matter of C:\ProgramData\<company name>\<program name>, which we're accessing as
Environment.SpecialFolder.CommonApplicationDatain C#. We're storing a data file which is supposed to be shared and updatable by any user. Once again, virtualization rears its ugly head, and this "shared" directory isn't really shared. I can work around this by granting the Users group full access to C:\ProgramData\<company name>\<program name>, but is this the "approved" way to deal with this? I'd appreciate any help you folks can give. Thanks! -
I've got an application written for Windows XP that I'm trying to get to run under Vista, and I'm having some issues related to UAC. I see several ways to tackle these problems, and I need some guidance on the "right" way to go about this. When our software runs for the first time, the user is prompted to enter a product key, which we store in the registry under HKEY_LOCAL_MACHINE\Software\<company name>\<program name>. Under Vista, this becomes virtualized, so that every user on the machine gets prompted for the key. Using the installer to put the key into the registry seems to avoid this problem, but this raises other issues. If we have the installer validate our product key, we'll need to build a DLL or script for the validation, and we're concerned about that being reverse-engineered/hacked. If the installer just puts the key in, and our software validates it when it runs, then we need to provide a mechanism for the user to correct a bad key, and we face registry virtualization again. We have a similar issue with some global settings which apply to all users, also stored in HKEY_LOCAL_MACHINE\Software\<company name>\<program name>. I can add a manifest to the program so that it has the privileges it needs to avoid virtualization, but then the user faces the wrath of UAC every time they run our program. There's also the matter of C:\ProgramData\<company name>\<program name>, which we're accessing as
Environment.SpecialFolder.CommonApplicationDatain C#. We're storing a data file which is supposed to be shared and updatable by any user. Once again, virtualization rears its ugly head, and this "shared" directory isn't really shared. I can work around this by granting the Users group full access to C:\ProgramData\<company name>\<program name>, but is this the "approved" way to deal with this? I'd appreciate any help you folks can give. Thanks!I have one application (Multipicity) that runs without a prompt for normal use but fires up a UAC prompt when I open the settings dialog, so I know what you appear to need is possible but not how to make it work. One work around I can thing of though: Can you put the registry updater in a separate executable and different security settings in the manifest?
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
-
I've got an application written for Windows XP that I'm trying to get to run under Vista, and I'm having some issues related to UAC. I see several ways to tackle these problems, and I need some guidance on the "right" way to go about this. When our software runs for the first time, the user is prompted to enter a product key, which we store in the registry under HKEY_LOCAL_MACHINE\Software\<company name>\<program name>. Under Vista, this becomes virtualized, so that every user on the machine gets prompted for the key. Using the installer to put the key into the registry seems to avoid this problem, but this raises other issues. If we have the installer validate our product key, we'll need to build a DLL or script for the validation, and we're concerned about that being reverse-engineered/hacked. If the installer just puts the key in, and our software validates it when it runs, then we need to provide a mechanism for the user to correct a bad key, and we face registry virtualization again. We have a similar issue with some global settings which apply to all users, also stored in HKEY_LOCAL_MACHINE\Software\<company name>\<program name>. I can add a manifest to the program so that it has the privileges it needs to avoid virtualization, but then the user faces the wrath of UAC every time they run our program. There's also the matter of C:\ProgramData\<company name>\<program name>, which we're accessing as
Environment.SpecialFolder.CommonApplicationDatain C#. We're storing a data file which is supposed to be shared and updatable by any user. Once again, virtualization rears its ugly head, and this "shared" directory isn't really shared. I can work around this by granting the Users group full access to C:\ProgramData\<company name>\<program name>, but is this the "approved" way to deal with this? I'd appreciate any help you folks can give. Thanks!Now that I've been through the pain of fixing our code to work with the UAC requirements is actually a really good thing. When we run for the first time and require registration stuff I launch a separate elevated process and write to hklm. I believe this is the correct thing to do as we are requiring a change to be made that will affect all users of the software so UAC should be invoked.
Bob Berge wrote:
We have a similar issue with some global settings which apply to all users, also stored in HKEY_LOCAL_MACHINE\Software\\. I can add a manifest to the program so that it has the privileges it needs to avoid virtualization, but then the user faces the wrath of UAC every time they run our program.
Here i believe that you should launch an elevated process when the user wants to change settings but not for the whole application. Settings that affect all users of the system should only be modified by administrative users running in elevated mode. Russ