Archive: Pending Separate Process?


Pending Separate Process?
  I tend to use NSIS to repackage vendor software at my organization. (Thank you to everyone that works on it, you guys have made software deployment much, much easier...)

This is my problem:

I launch the execution of the software via ExecWait, and it will crash the install, because that piece of software launches another process, and closes out. (ex: Watch Adobe updates install - you launch setup.exe; it in turn launches PDApp.exe and closes out.) This becomes problematic when your nsis installer is setup to clean up the update files at the end of the installation, and deletes the install files while they are trying to be installed.

so this is what I've done to prevent that, using Processes:


Section "the App"

File /r "install.bat"
File /r "launch_silent.vbs"
ExecWait 'wscript.exe launch_silent.vbs'

>; launch_silent.vbs just calls install.bat silently:
;CreateObject("WScript.Shell").Run "%TEMP%\install.bat",0
>; for the sake of this problem, we arent able to modify install.bat, and have to use it to do ; the installation.

>call Check4process
SectionEnd

>Function Check4process
Processes
::FindProcess "cmd.exe"
IntCmp $R0 1 0 Installed
sleep 6000; sleep for 6 seconds
Call Check4process; check again
Installed:
>FunctionEnd
>

Now the vbs calls the .bat file, that runs as a process 'cmd.exe'. Check4process checks for cmd.exe and if it is running, it sleeps. Else, it exits, and continues with the installation. The problem I've come to is, say the customer has another cmd.exe (checking ipconfig or something..) my installer is paused until all cmd.exe windows are closed.

I've tried a couple of things, but I haven't had any luck at this time, and thought I would ask those with way more experience if I've completely botched the use of nsis, or if I'm just missing something that's actually pretty simple.

Have you tried to find out if there are any switches that forces it to wait?

Or you could try http://nsis.sourceforge.net/ExecWait...th_Job_Objects


Anders:

Thanks for the response! There aren't any switches in the .bat file that would pause it, or that I can invoke. It's all or nothing.

Your suggestion works wonderfully for Windows XP Professional SP3 (32-bit) but hangs the install when ran against windows7 Enterprise (64-bit). Any suggestions to what I can change in the macro to accommodate the architecture difference?

In the past I've put in checks for architecture and changed up the sections / function calls based on it, but I'm still really new to using macros or, for that matter, system calls.


That code has not been touched in years, I don't know what the problem could be, sorry


ExecDos is what I wound up using. Since I was able to remove the vbs, as long as the .bat windows doesn't show, this was ideal, and works on both XP and 7.


How does the batch file know the process has completed?

Stu


Originally posted by Afrow UK
How does the batch file know the process has completed?

Stu
I was over complicating the issue (I do that sometimes...okay, a lot.) I was using the .vbs script to launch install.bat silently. Once I found ExecDos, I didn't need the .vbs anymore, greatly simplifying the process. NSIS could launch the install.bat file directly, and monitor when it terminated to continue with the process.

The batch file was the payload in this instance, so when it completes, the installer can continue with what it needs to do, in this case, ftp the resulting log file to a ftp site where we can take a look at the results later.

You are probably still overcomplicating by using a batch file. Whatever you are doing in the batch should be doable in NSIS script. So, how does the batch file know the process has completed?

Stu


Stu,

Yes it is still being complicated by using the batch file. The batch file is from the vendor; They use it to audit systems for compliance (hence, I'm not allowed to modify it...). As my workplace is very diverse (separate departments have their own IT, for example) When releasing the audit batch file to them, we have to make sure that we can get the log file back for evaluation.

That's what I meant when I said that the batch file was the payload in this instance.