Reputation: 19012
Application2 was orginally developed an application for WinXP. Now I have to contend with User Account Control (UAC) on Win7. The Application2 runs fine on Win7 as long as the user is logged into an Administrator account and they select "Run as administrator." However, I am trying to evaluate whether it is possible to refractor Application2 so that it does not require an Administrator account and "Run as administrator." I would also like to avoid any dialog boxes requiring users to make a choice if possible.
Application2 features that currently require "Run as administrator"
C:\Program Files\MyApp
C:\Program Files\MyApp
C:\Program Files\MyApp\MyData
Number 6 can be solved by relocating this folder to My Documents (its location is stored in the registry*), or granting the user "Full control" permissions to C:\Program Files\MyApp\MyData
, or letting Win7 make the necessary modifications in the VirtualStore folder.
Numbers 3 and 4 is more difficult to deal with because Application1 has to read files in C:\Program Files\MyApp
. Application1 will not be using "Run as administrator," and I need to do more research to figure out how the VirtualStore folder can be used to bridge the gap between Application2 and Application1.
As for the other points, I am trying to figure out options:
*Thinking out loud here: I would need to delete C:\Program Files\MyApp\MyData
after copying to C:\My Documents\MyData
, and I would need to modify the registry key storing the folder path, maybe these steps could be done during installation.
Discoveries
On Windows 7, even without "Run as administrator" you can:
C:\Users\Public\Documents
or C:\Users\currentuser\Documents
HKEY_CURRENT_USER
Furthermore, I believe it is dangerous to have a Windows 7 application without a UAC Application Manifest file. Because, if you don't have one, Windows 7 decides for you whether to run the application in Compatibility Mode or not. If you have one, you can specify how your application needs to run.
Upvotes: 1
Views: 1674
Reputation: 942207
No, you can't do these things without getting elevated. The point of UAC is not to stop you from doing this, it is to let the user know that you're about to do this. An obvious and valuable property of UAC is that it doesn't provide a backdoor to do these things anyway without the user knowing about it. This is not a problem, it is a feature.
What you describe doesn't strike me as something that needs to happen frequently. This should not wear out the user. If that's an issue, you can run it from a scheduled task using an admin account.
Upvotes: 2
Reputation: 18974
The best thing to do is to change your application - only slightly, mind you - so that it will run as a non-elevated user. To help you do that, I have to point out some subtleties.
For example, point 1, "read and write registry keys", is overly general. Applications that are non elevated can and do read and write registry keys with no problem at all. The restriction is that you can't write registry keys in HKLM. So you can avoid UAC issues if you change your code to use a key under HKCU, or if you refactor some of your code into an admin/config/setup app that runs elevated and writes keys to HKLM, and an ordinary app that reads those keys but never writes them.
Point 2 and 3 are both "can't write to anything under Program Files." Change your code so that the files you need to copy/delete/encrypt/decrypt are not under Program Files. AppData is a popular (per user) location for this.
Stay away from the whole virtualization thing and deliberately trying to use the Virtual Store. It confuses users tremendously. Instead, gain a firm understanding of the behaviours that non-elevated apps can't execute, and adjust your code to perform the (very similar) replacement behaviours, such as using HKCU instead of HKLM or AppData instead of Program Files.
Upvotes: 1