Windows Vista Application Development Requirements for UAC Compatibility


Our updated guidance for ISVs is now available for you to download at the Microsoft Download Center. We’ll have a “browesable” form on MSDN as part of the Windows Vista Developer Story shortly, as well. I’ll post a link on the blog when it goes live.


The download page for the “Windows Vista Application Development Requirements for UAC Compatiblity” document is here: http://www.microsoft.com/downloads/details.aspx?FamilyID=ba73b169-a648-49af-bc5e-a2eebb74c16b&DisplayLang=en.


-Jenn Allen


Comments (10)

  1. Pete Cole says:

    This document gives this:

    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">

    All other prior documents (and loads of blogs) I have seen state .v3.

    Is this a typo in this new document?

  2. Brian Bucklew says:

    Hey there, We’ve apparently found some drawing bugs with CreateProcessFromUser called from a service in Vista RC1, and I would like to get in contact with someone from the UAC team to discuss this and other apparent bugs in RC1. This document appears to indicate our methodology should work. Could someone please contact me at bbucklew@scriptlogic.com?

  3. CoqBlog says:

    Une guide (en anglais)&amp;nbsp;est disponible en t&#233;l&#233;chargement (doc, 91 pages) pour ceux qui veulent s’assurer…

  4. Nishant says:

    It is most comprehensive document on vista development. As per previous documentation virtualization cab be turned on or off through registry, HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionpoliciessystemEnableVirtualization. Is there any way we could know if in past whether the virtualization was turned on or off? Regarding the task scheduler, it is quiet innovative now.

  5. Please consider adding another value for requestedExecutionLevel attribute in the manifest, that would specify that the application should be run in the standard user context by default.

    Consider the following scenario: a user is running an application in the standard user context. Later, the user wants to check for updates to the application, so she starts a special updater, in the administrator context. The updater detects that the new version is available, so it shuts down the application, installs the updates, and now it needs to restart the application. Currently, it can only restart it in the administrator’s context (because the updater itself is running in the administrator context), which is not good. If there were a special value reserved like asStandardUser (in addition to asInvoker, etc.), then the updater could restart the application in the standard user context automatically.  

  6. Tyler says:

    Andrei:

    Elevation to administrator is a one way trip, the best of my knowledge.  If you are a standard user and you elevate to an administrative account, you’re a different user entirely… how do you determine whether to become the unelevated administrative account versus a different account?

    There are other ways to relaunch your application in the context it was launched – you might consider something like:

     1) mainapp.exe sees update online.

     2) launches updatehelper.exe [asInvoker]

     3) mainapp terminates, updatehelper launches updater.exe [requireAdministrator]

     4) updater.exe does work, updatehelper.exe waits until updater.exe quits, then restarts mainapp.exe, then quits.

  7. Tyler:

    thanks for your reply. You wrote:

    "Elevation to administrator is a one way trip, the best of my knowledge.  If you are a standard user and you elevate to an administrative account, you’re a different user entirely… how do you determine whether to become the unelevated administrative account versus a different account?"

    From what I’ve learned about UAC, elevating the privileges does not use an entirely different account: instead, it uses a different token (with more privileges attached to it), but the token belongs to the same account. Since the system has the ability to choose which token to use when creating each specific process, it seems logical to allow the administrative applications to choose _programmatically_ which token to use, as well. Of course, the process running with the standard user privileges should not be able to use the "full" token, but the process running with the full token should be allowed to downgrade its children’s privileges, if necessary.

    >> There are other ways to relaunch your application in the context it was launched <<

    Yes, such a workaround should work, yet it seems rather clumsy, to create one more executable (updatehelper.exe) just for the purpose of being able to _reduce_ the access rights of the child processes. If it’s still not too late to make changes in UAC, I would urge whoever is designing UAC, to seriously consider adding such a capability. I know I’m not the only one who is asking about this, other people started posting in the microsoft newsgroups with questions like mine.

    Thanks again!

  8. Tyler says:

    Standard users (aka restricted users on XP) don’t have an ‘administrator’ identify.  When you attempt to elevate, you get prompted for a different, Administrative, user’s credentials.

    Moreover, you can actually elevate a member of the administrators group to another member of the adminstrators group, too, if you set the ‘behavior of the consent prompt for administrators’ policy to ‘prompt for credentials.’

  9. William says:

    So, how does an application get elevation on a per-operation basis like the file explorer does?  Will calls like SHFileOperation() do that?  (Trying to figure out how you make an application install fonts when running normally.  Or if you have to have some sort of doofy font installer program that you run elevated.)  And I notice that now it is hard for users to edit system stuff, but there is no formal way to actually install anything per-user (fonts, file types, anything involving the registry or system directories), you can just let stuff fall through to the virtualization, but that might not be turned on.

  10. CoqBlog says:

    Une guide (en anglais) est disponible en téléchargement (doc, 91 pages) pour ceux qui veulent s’assurer