Quote:
Originally Posted by Anders
ExecShell nor any kind of ExecShellWait is enough to reliably start a process elevated, this is bad advice.
|
Sure,
ShellExecute(Ex) cannot "reliably" start an elevated process from a non-elevated one, because the user has to explicitly agree in the UAC dialog to launch the process. If the user doesn't agree (or the timeout hits), the process won't start. And, if the current user in
not "admin", he even has to enter "admin" credentials into the UAC dialog in order to launch the process.
But: Using
ShellExecute(Ex) it's at least
possible to start a process that requires "elevation" from a
non-elevated process (and if user declined, you can detect the issue and just retry) - whereas
Exec or
ExecWait just
fail in that situation with error #740.
See also:
http://blogs.msdn.com/b/winsdk/archi...plication.aspx
Quote:
Originally Posted by Anders
A) Vista, 7 (and 8?) with UAC turned off.
|
I think if UAC is turned
off, then
ShellExecute(Ex) just launches the "elevated" process
without showing the UAC dialog. In this special situation
Exec or
ExecWait could do the job too, but they'd start
failing as soon as UAC is actually
not turned off on some computer.
ShellExecute(Ex), on the other hand, works fine under both conditions, I believe.
Quote:
Originally Posted by Anders
2000, XP and 2003 with non-admin credentials used in the runas dialog.
|
Since these "legacy" systems didn't have UAC, they just ignore the "elevation" request from the Manifest.
If a "non-admin" user launches your installer on any of
these systems (or an "admin" user uses
run as to run your installer under a "non-admin" account), you have a problem anyway! The installer needs to detect this via UserInfo plug-in and abort...