Application Manifests, UAC & Windows Vista - Part 2

Way back in the days of Windows 2000, new guidelines were introduced to improve the overall usability and security of the OS.  Although, in order to maintain compatibility, none of these guidelines were actually enforced at the time.  Then, when Windows Vista was released, the game changed.  Those guidelines were no longer optional, but there was a backup plan.

New Guidelines for Windows 2000

1. Only binaries or read only files should be stored in Program Files.
2. Any documents or user created files should be stored in My Documents.
3. Temporary files should be created in the user (or system) Temp folder.
4. Anything else should be written to Application Data.

Now, in a perfect world, everyone would have read those guidelines and started following them.  After all, there is no shortage of documentation on how to implement them, but things rarely go according to plan.  Even we were not immune to this thinking.  I guess it could be summed up as "Well, if Microsoft doesn't care if we do it, then why should we change?"  And, you can't exactly cry foul just because you didn't read the rules, can you?

With the introduction of UAC, it was no longer possible to write to Program Files without administrative privileges, but somehow older programs still worked.  This is where the the requestedExecutionLevel flag in Application Manifests comes into play.  If the flag is missing from the manifest, the OS does its fancy footwork of guessing whether the program should be elevated.  If the program is not elevated, then the program is run in compatibility mode.  Any attempts to write to a system folder - such as Program Files or System32 - or write to a system registry hive - such as HKLM - will result in virtualization.

While you may think your program is writing to HKLM, it's not.  Not really.  It may look like it to you.  Even to the program itself, it will appear that way, because it is actually reading from a virtualized section of the registry.  This means that in your own little world, everything is working as you expected, but it is not directly affecting the OS.  So, any changes you make to your little world don't affect anyone else who logs into the OS.  This is one of the key points that makes UAC really work.  Without this, Vista would truly be the nightmare that you hear in those Mac commercials.

Still, even with virtualization in place, some wacky things can occur.  for example, there's a specific case I found with the SDelete utility provided by SysInternals, which runs in compatibility/virtualization mode.  If the program is run as unpriviledged and is passed a file located in Program Files, it simultaneously finds the file and cannot find the file.  It actually finds the file in Program Files, and then attempts to open a file of the same name in the Virtual Store.  So, after all that, it reports a success saying the file was correctly wiped and deleted, but the file in Program Files is never touched.

User Account Control (UAC)

• UAC Architecture 
• Designing UAC Applications for Windows Vista 
• New UAC Technologies for Windows Vista 
• Common file and registry virtualization issues in Windows Vista or in Windows 7 
• UAC - What. How. Why.