ExecWait as user - NSIS Forums

azureusvuze
10th March 2013 09:57 UTC

ExecWait as user
Anyone have plugin which can ExecWait as user privileges?

Usually i used:
Push "$EXEDIR\${APPDIR}\${APPEXE}"
Push "open"
Push '${APPSWITCH} $0'
StdUtils::ExecShellAsUser /NOUNLOAD
FindProcDLL::WaitProcEnd "${APPEXE}" -1

Anders
10th March 2013 15:17 UTC

If you need to run a application as the user (other than the finish checkbox) you are probably doing something wrong...

LoRd_MuldeR
10th March 2013 22:47 UTC

What you want is not possible the way "ExecShellAsUser" works. The implementation of ExecShellAsUser in the StdUtils plug-in is based on the IShellDispatch2 COM interface. And if you look at the ShellExecute function, you'll see it is rather limited, compared to the "native" ShellExecuteEx function. It does NOT return a handle we could use for waiting. Can you explain what exactly your use-case is?

azureusvuze
16th March 2013 07:35 UTC

Originally posted by LoRd_MuldeR
What you want is not possible the way "ExecShellAsUser" works. The implementation of ExecShellAsUser in the StdUtils plug-in is based on the IShellDispatch2 COM interface. And if you look at the ShellExecute function, you'll see it is rather limited, compared to the "native" ShellExecuteEx function. It does NOT return a handle we could use for waiting. Can you explain what exactly your use-case is?

Installer is executed as administrator privileges, but will execwait app.exe as user privileges.
Is this possible?

MSG
16th March 2013 10:30 UTC

Originally posted by azureusvuze
Installer is executed as administrator privileges, but will execwait app.exe as user privileges.
Is this possible?

This is possible with the UAC plugin, but it's not easy. But like Anders said, if you need this, you are probably doing things in a very broken way. Reconsider your approach carefully, you are most probably trying to make an application that is not Windows compatible.

LoRd_MuldeR
16th March 2013 14:15 UTC

Originally posted by azureusvuze
Installer is executed as administrator privileges, but will execwait app.exe as user privileges.
Is this possible?

Again: What exactly are you trying to do? Usually there is only one use-case to run applications with user-privileges from an elevated installer: You are done installing and now want to launch the app you've just installed. But you don't want that app to run elevated. In that case, you don't need to wait for that app, of course... Why do you need to wait for the app and need it to run with user-privileges?

azureusvuze
17th March 2013 07:45 UTC

Originally posted by LoRd_MuldeR
Again: What exactly are you trying to do? Usually there is only one use-case to run applications with user-privileges from an elevated installer: You are done installing and now want to launch the app you've just installed. But you don't want that app to run elevated. In that case, you don't need to wait for that app, of course... Why do you need to wait for the app and need it to run with user-privileges?

I try to make portable app launcher like portableapps.com, launcher need to be run as administrator to backup and restore registry, but target need to be run as user privileges.

Like this:
registry::_DeleteKey /NOUNLOAD "${_REGKEY}-BackupBy${APP}Portable"
registry::_MoveKey /NOUNLOAD "${_REGKEY}" "${_REGKEY}-BackupBy${APP}Portable"

ExecWait app.exe

registry::_DeleteKey /NOUNLOAD "${_REGKEY}"
registry::_MoveKey /NOUNLOAD "${_REGKEY}-BackupBy${APP}Portable" "${_REGKEY}"

LoRd_MuldeR
17th March 2013 13:58 UTC

So, do I get this right? You have an application that is not "portable", but you try to pretend it is portable by silently installing (i.e. setting up registry keys and stuff) the application right before its launched and again silently uninstalling the application after it has terminated?

I guess the only way to achieve that currently is what MSG has suggested already: Use the UAC plug-in. But even more important: Instead of inventing ugly workarounds, why not make your application "portable" right away, so these workarounds are not needed any longer ???

Highcoder
17th March 2013 14:33 UTC

I think its because "his" app is not his app. ;)
And the most of all programs that are designed to be installed normally need this keys to run.
But these apps are not portable with this workaround.
Portable means you can run this app on every (windows)machine without adminrights an installing.
Your thing is not portable at all because you need adminrights for your "launcher" to set the necessary keys.

But the most people use "Portable" Apps because they have no mess on their PC caused by bad uninstall routines that doesn't clean up and left a lot of files an regkeys.

LoRd_MuldeR
17th March 2013 17:52 UTC

Originally posted by Highcoder
I think its because "his" app is not his app. ;)

Then there are two possibilities: The app that is not "his" is OpenSource/FreeSoftware and thus can be "fixed" to be portable. In that case we don't need the workarounds. Or that app is proprietary, in which case he might not even be allowed to redistribute it! Only real case I see is, when the app is proprietary but still allows redistribution under a Freeware license (and also explicitly allows repackaging). And, in that particular case, I would still try to contact the developer can get him convinced to release a "real" portable version, first...

If nothing else helps and if also the UAC plug-in method isn't acceptable, he could also do this: Create a "base" (wrapper) installer that explicitly runs with user privileges. In that installer, include two more installers that will run with admin privileges: One to prepare starting the app and one for cleaning up afterwards. Then he could do something like:

ExeShell '"$PLUGINSDIR\prepare-installer.exe"'
ExecWait '"$PLUGINSDIR\the-not-so-portable-app.exe"'
ExeShell '"$PLUGINSDIR\cleanup-installer.exe"'

Only drawback: User will have to accept an UAC dialog twice...

azureusvuze
19th March 2013 06:23 UTC

Originally posted by LoRd_MuldeR
Then there are two possibilities: The app that is not "his" is OpenSource/FreeSoftware and thus can be "fixed" to be portable. In that case we don't need the workarounds. Or that app is proprietary, in which case he might not even be allowed to redistribute it! Only real case I see is, when the app is proprietary but still allows redistribution under a Freeware license (and also explicitly allows repackaging). And, in that particular case, I would still try to contact the developer can get him convinced to release a "real" portable version, first...

If nothing else helps and if also the UAC plug-in method isn't acceptable, he could also do this: Create a "base" (wrapper) installer that explicitly runs with user privileges. In that installer, include two more installers that will run with admin privileges: One to prepare starting the app and one for cleaning up afterwards. Then he could do something like:
ExeShell '"$PLUGINSDIR\prepare-installer.exe"'
ExecWait '"$PLUGINSDIR\the-not-so-portable-app.exe"'
ExeShell '"$PLUGINSDIR\cleanup-installer.exe"'
Only drawback: User will have to accept an UAC dialog twice...

Too many exe to be run.
I'll back using StdUtils and FindProcDLL (mod by hnedka).

Thanks for your answer.