Win7 UAC problems when running application designed for WinXP

Question

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"

1. Create System Data Sources (ODBC)
2. Read/write/delete registry keys
3. Copy/delete files in C:\Program Files\MyApp
4. Encypt/decrypt files in C:\Program Files\MyApp
5. Start .exe processes located in a shared folder on a remote machine
6. Start VBScript processes that install Office Add-ins and read/write/delete registry keys
7. Copy/delete/modify files in 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:

1. Please let me know if/how it is possible to perform these actions under a non-Administrator user account and without "Run as administrator."
2. Please let me know if any of the actions are impossible without being an Administrator.
3. Feel free to point out any technical mistakes that I may have made in the contents of this question.
4. Again, I am trying to avoid dialog boxes during application runtime.

*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:

1. Create/delete User Data Sources
2. Create/modify/delete files in C:\Users\Public\Documents or C:\Users\currentuser\Documents
3. Create/delete registry keys in 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.

Answer 1

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.

Answer 2

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.