Quote:
Quote:
And it doesn't just Do The Right Thing if you turn off UAC?

Well. If UAC is on then your request for C:\Program Files\SuperApp\Config.ini goes to something like C:\Users\tfabris\appdata\SuperApp\config.ini. If you've installed your app with UAC on and then turn UAC off at a later point then stuff will have "vanished" until you turn UAC back on. You don't get any fine grain control about what parts of UAC you're turning off. Its everything or nothing.


UAC also isn't fully redirecting things here either. Execute requests to files that somehow end up in both places prefer C:\Program Files over C:\Users. Why is this bad? Well, if a legacy program is installed, UAC detects it and prompts to elevate it. So far so good, the legacy app can install executables to C:\Program Files like it needs to. Now the installer is closed, and a user runs the app without elevated privileges. The legacy app has a self updating function, so it scans a second binary in C:\Program Files, finds that it is out of date and downloads a new one. UAC redirects the write to C:\Users. The program then tries to execute the second binary, thinking it is up to date, and executes the one in C:\Program Files, and NOT the newly downloaded one in C:\Users. So now you have an out of date executable running, even though a process downloaded a newer one.