ShellExecAsUser plugin

[LoRd_MuldeR]

I have updated my StdUtils plug-in to use the "new" plug-in API, i.e. get rid of explicit unload.

Furthermore I added a version of ExecShell with wait capability as well as some more convenience functions.

New version here:

http://nsis.sourceforge.net/StdUtils_plug-in

(BTW: Could some mod please delete the obsolete versions attached to my previous posts?)

[LoRd_MuldeR]

In case somebody is interested, I just uploaded a new version of my StdUtils plug-in:

http://nsis.sourceforge.net/StdUtils_plug-in

[LoRd_MuldeR]

In case somebody is interested, I just uploaded a new version of my StdUtils plug-in:
http://nsis.sourceforge.net/StdUtils_plug-in

I've just uploaded yet another update, which fixes a potential crash related to CoUninitialize() and certain certain Shell Extensions. In my case it was Tortoise GIT. Put simply, CoUninitialize() might still crash, even if all COM interfaces were released properly before. Happens if there are outstanding messages. It turns out we must dispatch all pending messages explicitly before calling CoUninitialize().

As this might be relevant for all NSIS plug-in's that deal with COM interfaces (and the Shell), you might want to have a look here:

http://stackoverflow.com/questions/13018389/ishelldisptach-why-does-folderitemverbsrelease-couninitialize-crash

[Theresias]

(As requested in the NSIS WIKI, I'm using this topic for feedback on StdUtils.)

LoRd_MuldeR, any plans to add a x86/x64 check to StdUtils? I am currently using...

code:
      System::Call "kernel32::GetCurrentProcess() i .s"

      System::Call "kernel32::IsWow64Process(i s, *i .r0)"

...but maybe there is a cleaner way to do this?

[LoRd_MuldeR]

NSIS has that built-in already

code:
!include "LogicLib.nsh"

!include "x64.nsh"



${If} ${RunningX64}

    MessageBox MB_OK "We are running on x64!"

${EndIf}

[Theresias]

LOL Nice, thanks. Back in the day that didn't exist...

[Anders]

LOL Nice, thanks. Back in the day that didn't exist...

The system::call code is still the same behind the scenes

[r2du-soft]

ShellExecAsUser not work in nsis unicode

hi

i use from ShellExecAsUser plugin for open the exe files run as user

Plugin:
http://nsis.sourceforge.net/ShellExecAsUser_plug-in


when i use the nsis ansi then ShellExecAsUser plugin works correctly and exe file opened.

Section
ShellExecAsUser::ShellExecAsUser "open" "C:\1.exe"
SectionEnd

but if use from the nsis unicode:

[B]Unicode true
[/B]
Section
ShellExecAsUser::ShellExecAsUser "open" "C:\1.exe"
SectionEnd

plugin unable to open file and show message:

[Anders]

There is no Unicode version of that plug-in. Try contacting the author.

Edit: A Unicode version has now been added to the wiki by the author.

[BerndS]

Hi
Does anybody know a method that I can force the main NSIS Process to wait for the ShellExecAsUser process to end before it is possible to do anything else?


Regards
Bernd

[Anders]

Does anybody know a method that I can force the main NSIS Process to wait for the ShellExecAsUser process to end before it is possible to do anything else?

No I don't believe that is possible. The COM interface used to ShellExecute does not support waiting. You need ShellExecuteEx to wait, and even then, it would not work because the wait handle is in the wrong process.

Why do you need to wait for a "as user" process?

[BerndS]

Hi
It is not essential to wait for the user process but it would feel better ;-)

I start a user process that does some downloads and configuration stuff when the main part of the installer is done. As I can click the "next" buttons in the NSIS part I can end the installer but the "user" part is not finished and is working ... this just does not look very nice.

Regards
Bernd

[Anders]

I start a user process that does some downloads and configuration stuff when the main part of the installer is done.

Assuming this is a "RequestExecutionLevel Admin + HKLM + $ProgramFiles" installer. These are multi-user installers and any per-user initialization should happen the first time a user runs the applications from the start menu. In a extreme case; someone could use fast user switching and start the application as a 3rd user (not the administrator and not the "user") before your call to ShellExecAsUser has completed.