I dont fuss with process and such things much so I'm asking for some help if you think you may have a solution for me...

I want to provide some level of synchronization between two active processes, they are both full Win32 applications, where one is created from the other as a result of the ShellExecute API.

Looking at the documentation, ShellExecute will:
Return Value

If the function succeeds, the return value is the instance handle of the application that was run, or the handle of a dynamic data exchange (DDE) server application.

I looked up the WaitForSingleObject api and found this clause in its list of triggerable handles:
The WaitForSingleObject function can wait for the following objects:

Process: The handle is returned by the CreateProcess or OpenProcess function. A process object's state is signaled when the process terminates.

So my thoughts was to try calling ShellExecute and then follow it by the WaitForSingleObject to hopefully hault the calling process untill the newly executed process terminates. But it doesn't work. The return is always WAIT_FAILED from the WaitForSingleObject API. My guess why is because i need to somehow translate an "application handle" into its "process handle".

Can anyone give me an idea how? Or if my gut feeling here is even the correct way to do this?
Posted on 2004-07-12 01:39:52 by NaN
I note that ShellExecuteEx can be used subsequently to your call to ShellExecute in order to gain more information about your child process, but I was wondering if you'd thought about using a Named Pipe for synchronisation?
Posted on 2004-07-12 02:51:43 by Homer
No i didnt think of using pipes for this type of work.. I never had a reason to learn them, but my understanding is they are for piping text output from one process to another. I was not aware they can be useful for process synchronization as well.

Posted on 2004-07-12 23:23:12 by NaN
ShellExecute returns pid
use OpenProcess to pid->hProcess
Posted on 2004-07-12 23:35:33 by comrade
One cheat is to have both processes map a common file (shared), and then, under FileMapping, read and write to the "file memory" which is being shared..
Posted on 2004-07-12 23:49:44 by Homer
From MSDN,
Returns a value greater than 32 if successful, or an error value that is less than or equal to 32 otherwise. The following table lists the error values. The return value is cast as an HINSTANCE for backward compatibility with 16-bit Windows applications. It is not a true HINSTANCE, however. The only thing that can be done with the returned HINSTANCE is to cast it to an int and compare it with the value 32 or one of the error codes below.

If you don't have a (good) reason for using ShellExecute(), I suggest you use CreateProcess().
Posted on 2004-07-12 23:56:43 by death
Pipes can be at times, tricky, especially when the OS goes into high usage.
If simple flow control is needed, consider a mutex or semiphore.

Regards, P1 :cool:
Posted on 2004-07-13 10:12:06 by Pone
Thank you for your help so far. I should qualify however, i cant modify the program I want to execute in sequence. Its a third party product with usefull command line switches. My program, the one calling the other, I have full flexibility over.

Have you tested or know your suggestion will work? Because if i read things correctly death's point should contradict your suggestion.

Thanks again for entertaining me this far..
Posted on 2004-07-13 16:07:06 by NaN
I do not fully understand what you are trying to do but here are some ideas.

Use CreateProcess instead of ShellExecute. It gives you *much* more control over the process. The lpProcessInformation structure will be filled in by CreateProcess. Inside of it, there is a field called hProcess. You can call any of the wait functions and use this handle. The wait will be completed when the process either exits or crashes. Once the wait has completed and you no longer need the handle to the child process CloseHandle both hProcess and hThread.
Posted on 2004-07-13 17:51:46 by Mecurius
Thanks Mecurius,

Since you asked, I wrote an automating program that will burn many PIC chips, each with a unique serial RFID. My program will essentially patch my PIC HEX code with an another ID, then call the PIC software to burn the next chip. My program outputs a list of generated and suscessfully burned chips, while automatically incrementing ID's for the next pass.

The CHIP burning software is a full third party windows application and makes use of the command line to automate it, if someone wanted.

My program all works perfect. However, the catch was i had to instruct the end users NOT to move on to the next RFID until the burn is finished. I couldnt enforce this, as i could not enforce any level of syncronization using ShellExecute. This has the *potential* of skipping ID #'s while the burning process is still on-going.

Hope that gives you a better picture.
Posted on 2004-07-14 23:11:48 by NaN
Your best bet is to use the CreateProcess function to start the application, and then use a timer to call GetExitCodeProcess. If it returns anything other than STILL_ACTIVE, you know it is no longer running. It may also give you more info about how the task exited aswell - was it successfull or did it return an error. I actually use the ProcessID returned in the CreateProcess function and call OpenProcess and CloseProcess each time I call the GetExitCodeProcess function, but the Process Handle returned should be ok.

I use this at work, where I wrote an application to start tasks on remote machines, and poll them to check whether they are still running or not, or kill them remotely.

Hope this helps

Posted on 2004-07-15 03:43:50 by Nick
Since you asked, I wrote an automating program that will burn many PIC chips, each with a unique serial RFID.
What do you mean by RFID? Your PIC has transponder inside?
I thought RFID is radio frequency identification. What is RFID regarding PIC?
Posted on 2005-12-23 05:19:34 by The Svin

Since you asked, I wrote an automating program that will burn many PIC chips, each with a unique serial RFID.
What do you mean by RFID? Your PIC has transponder inside?
I thought RFID is radio frequency identification. What is RFID regarding PIC?
I would guess it's more like a GUID, than a RF transmitted ID.  But then again, this PIC may have a RF circuit too.  NaN is a pretty smart person.  :)

Regards,  P1  8)
Posted on 2005-12-30 20:28:56 by Pone

Is it worth the effort to get the exit code if the app that burns the chip actually returns an exit code ? As long as you use CreateProcess() you can check the termination code with GetExitCodeProcess() to determine if it has finished or not.

If simply sequencing one action after another, there is a number of ways to call the burn app passing it wahtever you want and then suspend the caller until the called app has terminated.
Posted on 2005-12-31 00:15:13 by hutch--
Hmm. This thread is over a year old.


I'm sure NaN was (still is?) programming a lot of PICs for that application. I'm not aware any PICs that have RF in them. It's a bit tricky combining RF with digital on a single chip for a variety of reasons. More likely, the PICs are communicating with an external RF circuit, with the PIC handling the data protocol, and maybe even the "bit banging".
Posted on 2005-12-31 19:10:10 by tenkey
Posted on 2006-01-08 01:24:30 by XCHG
Bad code, XCHG. You're not doing CloseHandle on hThread and hProcess, and it's better to use WaitForSingleObject on hProcess instead of polling GetExitCodeProcess.
Posted on 2006-01-08 09:05:06 by f0dder
Win32 Appllications don't need to do that, because the handles are closed automatically by the Windows operating system when the user closes the application. right when we show the message box
Posted on 2006-01-08 21:09:34 by XCHG
xchg, where did you read that?
Posted on 2006-01-08 21:17:32 by JimmyClif
Yes, fortunately the operating system DOES do cleanup for you when you ExitProcess (well, on win9x there's serious issues with GDI objects that won't get cleaned up). But not releasing handles (and freeing up memory, etc) is pretty bad coding style, and must be pointed out so people don't blindly adopt the code and run into problems later on.
Posted on 2006-01-08 21:22:48 by f0dder