redirecting stdio for sequential programs in an MFC dialog

Dennis Foreman
0
Reputation points
My C++ MFC dialog creates 2 child processes sequentially. I redirect STDOUT to separate files for each of the programs (and restore to default after each one runs). STDOUT from program 1 gets sent to its file as expected. Program 2 STDOUT disappears. Both programs return 0. I know Program 2 runs because a MessageBox it creates for debugging appears. To remove any other effects, I have reduced Program 2 to just: std::cout<<"aha"<<std::endl;
Is there anything I should know about doing this? PS. I have no access to the source code for the REAL programs 1 and 2.
{count} votes
Narrative descriptions don't provide much diagnostic information. Posting a relevant code snippet would be helpful.
Reversing the order was interesting. Program 2 (now running as program 1) still does not output anything, but still pops its MessageBox window, so it DOES run. Here is it's code, followed by the code for redirecting STDOUT:
The code for setting up and running CreateProcess is identical for both programs, except for the names of the programs and program 2 has no parameters.
Show us how you're doing that then.
I don't see how a child process can get a redirected handle from the parent since it does not appear that an inheritable file handle was created by the parent.
The handle was created by the function: redirect_stdio_magick near the top of my pasted code. The child then inherits this redirection. A copy of that function is used for Program 1 of my original description, with the only difference being the name of the file to be written. I will attempt to edit my post and format that line.
Tried to format it as bold, but couldn't get it to stay. So there is a ** in front and after that line. IT's the 10th line of the post (not counting empty lines).
Is fp_magickout a FILE* or a Win32 HANDLE?
FILE* and global
and it is global
Was your problem solved? Is there new errors?
Sign in to comment
1 answer
Sort by: Most helpful
Although the CRT will create inheritable files, the STARTUPINFO struct uses Win32 HANDLE types, not FILE* pointers returned from CRT functions.
For example, to obtain the low-level HANDLE for use with STARTUPINFO from a CRT FILE* pointer -
@Dennis Foreman By the way, If you close files using the CRT functions then do not call CloseHandle on hFile.
I had to do a minor change to use _wfopen_s instead of _tfopen like this:
My new code successfully created the handle , but when I used it here: si.hStdOutput = hFile_out_magick;
I got a "debug assertion failed" error when Program 2 ran. I pasted a screenshot of the error message but it disappeared.
I can't diagnose problems in code I haven't seen so you can look at the code that I used in my own example.
MFC Dialog Application Functions -
Console Application -
And the results of running the code -
I see what you are doing for ONE handle, but I cannot find any reference online for a PROC-THREAD-ATTRIBUTE- HANDLE-LIST (had to use dashes, because this system wouldn't let me use underscores for the keyword). I need to override both SYSOUT and SYSERR. SYSIN will not get used, so needs to be NULL. Can you advise me on that. I want to try your method. But, this doesn't explain why my method works for my Program 1.
The different attributes that can be used are documented at UpdateProcThreadAttribute function. To use more than one HANDLE put the handles that you want the child process to inherit in an array and pass the address and size to this function.
Redirecting standard handles within a process with _wfreopen is completely different from passing an inheritable Win32 HANDLE through the STARTUPINFO struct to a child process.
thanks. I'll read your reference and try building the array. If I get it to work, I will use it for both programs. Your source code is very helpful.
Passing two inheritable handles -
@Dennis Foreman if my suggestions and sample code for using HANDLEs in STARTUPINFO has resolved the child process inherited file output issue kindly accept the answer to close the question.
Sign in to comment
Activity