I have a console application that I launch from a GUI applicaiton. The console application takes parameters for filenames to parse and process. Currently I am able to captur
Check this out to see that you need to create both pipes (by calling the WINAPI twice) as reiterated by Nat but what about the inheritable handles - not sure why this is needed?
http://support.microsoft.com/kb/190351.
I think what might also be confusing is that when you create a pipe you are creating a read handle and a write handle for that pipe. In the case of the console's stdin pipe you will only use the write handle. Then you create another pipe for the console's stdout (which will also have a read and write handle) but you will only use the read handle.
I believe I have that correct but it is late and I'm going to bed.
You need two pipes, one for the process to send output to you (stdout
), and one for you to send input to the process (stdin
).
From your code, it looks like you are putting both ends of the same pipe into the TStartupInfo
record. So you are effectively making the process talk to itself. :-)
So, you need to call CreatePipe()
twice, to create two pipes, one for stdin
, one for stdout
(and stderr
).
Then, put the reading handle of stdin
in suiStartup.hStdInput
and the writing handle of stdout
in suiStartup.hStdOutput
To send data to the process, write to the write handle of the stdin
pipe. To read the output of the process, read the read handle of the stdout
pipe.
Edit: (again)
As for all the duplicating handles and inheritable and non-inheritable stuff described on this page (specifically in the code example), you need to make sure the handles you send to the process are inheritable (as you have done).
You should also make sure the handles of the pipes that the parent process use are not inheritable. But you don't have to do this... I've gotten away with not doing it before.
You can do this by either calling DuplicateHandle()
on the handles, specifying they are not inheritable and closing the old handles, or calling SetHandleInformation()
with 0 specified for the flags (as discussed here).
It's been a while since I have done this myself, but I'm pretty sure this is so that the reference count for the handles is associated with the calling process, rather than the child process. This prevents a handle being closed whilst you're still using it (the calling process might close 'stdin' for example). Make sure you close the handles though, otherwise you will end up leaking handles.
HTH.
N@
Along with output pipeline there's an input pipeline. Just write to that pipe using WriteFile().