A process either runs elevated or it doesn't. A process cannot change from an unelevated state to an elevated one.
A process can request to spawn an elevated sub-process in which case the UAC prompt will be shown. Or it can request an elevated instance of a COM server in which case the UAC prompt will be shown. In the second scenario, if the process holds on to that COM object for the rest of the process's lifetime, then it won't cause the UAC prompt to be shown again. To give an example of the second scenario, I have a legacy app that writes to HKLM (on which other parts of the program suite rely). I pulled the HKLM-writing code out into a COM server. My legacy app (when running on Vista or Win 7) requests an instance of the new COM server, at which point the UAC prompt is shown. If the UAC prompt completes successfully (either because the program was being run by an admin who confirms the elevation, or an admin username/password combo is correctly entered) then my legacy app holds on to that COM server instance for the rest of the session to enable continued successful HKLM writing without further UAC prompts. One can google for the circumstances under which Vista will determine a program to be requiring elevation up front (these include having the word "setup" in the filename, which is how most installers automatically request elevation on startup). Or one can include a Vista manifest indicating the elevation status that the application requires. If you set it to "requireAdmin", then the app will always present a UAC prompt on startup, and won't continue without successful completion of that UAC dialog. An installer isn't an "installer" from the POV of Vista/Win7. Installers are simply examples of programs which Vista always runs elevated. I could well be wrong, but I don't believe Windows controls or monitors the scope of elevation timespans as you suggest John. I believe it's simply a question of each application determining it's own elevation status (through manifests, etc) and controlling the elevation status and lifespan of any child-processes or COM objects that it instantiates. Cheers, Conor -----Original Message----- From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of John Bird I have noticed that it must store the process ID or something similar of the original parent process that needed and was granted the elevation. If the same action requiring elevation is run again it does not ask as long as the original program or one started by the original program is still running and repeating the same action. However if the program is terminated and restarted it does ask again. It shows there was some thought by MS into giving the elevation some scope over actions and processes related to the original process, and probably for some time as well, all of which is sensible. (In my case it was not registry stuff, but a starter program copying .Exe files wich does trigger Vista into thinking its some kind of installer I am guessing - which is similar to what you are doing) _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
