If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I just happened to realise that the WinExec API does not function under
Windows 7 (haven't tried under Vista yet, but will do soon) when the application has a manifest requestedExecutionLevel asInvoker.
with requireAdministrator however it works ofcourse.

Is there a way around this?

As a replacement I'm currently using the ShellExecute API to execute .exe's, but the problem with this API is that it requests command line arguments separately, so I have to personally code & detect and pass them on, where as on the WinExec API it does it for you.

Any solutions?

_____________________________________________________________________----If this post has helped you. Please take time to Rate it.
----If you've solved your problem, then please mark it as RESOLVEDfrom Thread Tools.

Re: WinExec API blocked by Windows 7 (when used with asInvoker)

I also have a app that is ran as invoker and uses ShellExecute to open online webpages (buy button, online help) and it works fine as a standard user on vista. Don't know about windows 7 from what i have heard if it works on vista it will work on windows 7. been waiting to see a difference. Are the exe's you are calling yours? If yes then maybe a manifest run as invoker with the exe's ?

I have a program updater that requires admin and if a standard user tries to do a update they are told to open as admin to do program updates using
Private Declare Function IsUserAnAdmin Lib "shell32" () As Long to see if they are admin.

Waiting for a full featured smart phone with out marrying a provider
Go Android
Go raiders

Are the exe's you are calling yours? If yes then maybe a manifest run as invoker with the exe's ?

Yes the exe is mine ,and It's already running asInvoker which is where the problem is.

requireAdministrator works fine.

_____________________________________________________________________----If this post has helped you. Please take time to Rate it.
----If you've solved your problem, then please mark it as RESOLVEDfrom Thread Tools.

Re: WinExec API blocked by Windows 7 (when used with asInvoker)

It seems that your real question is whether you can enter an entire "command line" in one piece using ShellExecute(). The answer seems to be a definite "no" based on the documentation.

WinExec(), like VB's Shell() function, is a fairly thin wrapper on the CreateProcess() function. CreateProcess() can be called in an insecure manner that allows this "all at once" command line:

Security Remarks

The first parameter, lpApplicationName, can be NULL, in which case the executable name must be in the white space–delimited string pointed to by lpCommandLine. If the executable or path name has a space in it, there is a risk that a different executable could be run because of the way the function parses spaces.

:

If a malicious user were to create an application called "Program.exe" on a system, any program that incorrectly calls CreateProcess using the Program Files directory will run this application instead of the intended application.

To avoid this problem, do not pass NULL for lpApplicationName. If you do pass NULL for lpApplicationName, use quotation marks around the executable path in lpCommandLine, as shown in the example below.

I actually got burned by this very exploit once, and always try to be careful to quote the program path now.

ShellExecute() is a much heavier-weight wrapper on CreateProcess() because it is a request asking the Windows Shell to carry out a verb upon a file. If the verb is null and the file is a program, then it acts like you used the "open" verb.

The reason it seems to act differently in Vista and later versions of Windows is that ShellExecute() now takes an even longer path. The Vista developer documents cover this in some detail. An excerpt:

Standard User Launch Path

The Windows Vista standard user launch path is similar to the Windows XP launch path, but includes some modifications.

ShellExecute() calls CreateProcess().

CreateProcess() calls AppCompat, Fusion, and Installer Detection to assess if the application requires elevation. The executable is then inspected to determine its requestedExecutionLevel, which is stored in the executable's application manifest. The AppCompat database stores information for an application's application compatibility fix entries. Installer Detection detects setup executables.

ShellExecute() looks specifically for this new error and, upon receiving it, calls across to the Application Information Service (AIS) to attempt the elevated launch.

Elevated Launch Path

The Windows Vista elevated launch path is a new Windows launch path.

AIS receives the call from ShellExecute() and reevaluates the requested execution level and Group Policy settings to determine if the elevation is allowed and to subsequently define the elevation user experience.

If the requested execution level requires elevation, AIS launches the elevation prompt on the caller’s interactive desktop (based on Group Policy), using the HWND passed in from ShellExecute().

Once the user has given consent or valid administrator credentials, AIS will retrieve the corresponding access token associated with the appropriate user, if necessary. For example, an application requesting a requestedExecutionLevel of highestAvailable will retrieve different access tokens for a user that is only a member of the Backup Operators group than for a member of the local Administrators group.

In Vista, process creation APIs behave very differently with respect to UAC. If you call CreateProcess() on an executable which is manifested as “RequireAdministrator” or is flagged as an installer by Vista, you will get back an ERROR_ELEVATION_REQUIRED (740) error.

When you call WinExec() trying to run msiexec.exe the CreateProcess() call fails if the first program is not already running elevated. This is because msiexec.exe is an installer and marked as such by Vista (or Windows 7).

Using ShellExecute() avoids this by letting CreateProcess() first fail, detecting the failure, and then sending the request on to AIS to handle presenting an elevation request if actually required. One thing is special about msiexec.exe: AIS will start it and query its state, and if msiexec.exe reports that it is doing a per-user install then AIS will silently let the install run unelevated. Qualifying for a true per-user install requires that several requirements be met however. Unless your program to be installed was written and packaged for it you do not want a per-user install anyway.

To make a long story short you'll need to use ShellExecute() if you have to spawn a process that requires elevation.