Redirecting stdout/stderr on child process to a window

[danebarney]

I'm developing a Windows CE 5.0 app using C# and I need to call a child
process and then capture its stdout/stderr into the textbox of a
window. So I'm P/Invoking the CreateProcess() function and the
SetStdioPathW() function. However, it seems that SetStdioPathW() is
intended for redirecting output to a file, not a window. What should I
be using instead?

 

[danebarney]

OK, so I read on a another post the following:

"Before calling CreateProcess(), call SetStdioPathW() and point that to
a
driver that you write and ActivateDevice() on. Come up with a means to
get
the data sent to the driver from it (you might pass it a window handle
to
which PostMessage() would be used, or you might specify that you'll
send a
DeviceIoControl() to the driver to retrieve the data, or whatever you
want)."

Now, what exactly is involved in creating a device driver? All I really
need it to do is pass text from the stdio of the child process to a
window textbox in the parent process.

 

[Paul G. Tobey [eMVP]]

A device driver is a special DLL that exports certain functions which the
system expects device drivers to have and which it calls in response to
application events (like the opening of the device name associated with the
driver). You can't do it in managed code; you'll have to use C/C++.

You might architect your driver such that it acts like a block device, so
you're application could P/Invoke CreateFile() to open it, and ReadFile() to
read data from it. How you would notify the application from the driver
when new data arrived is up to you and the only major unknown.

Paul T.

 

[danebarney]

OK thanks. But is this really the easiest way to do it? It seems like
such a pain to have to write a driver just get the functionality I
need.

 

[Paul G. Tobey [eMVP]]

Your functionality is not something that anyone to speak of wants to do.
95% of applications running on Windows CE are GUI applications, so who cares
about the standard out strings? Since you must have the source for this
application (you ported it to CE, apparently), why don't you come up with
your own means of sending the same data to another application as is being
sent to stdout (a socket or a point-to-point message queue or whatever)?
You can send it to a file, too, if that helps (open the file, pass the
handle to the file when setting the standard I/O target). You don't have to
write a driver for that case, but you're going to be polling for file
changes quite a bit and might eventually run out of 'disk' space, if the
application runs for a long time.

Paul T.