Re: CreateProcess() anomaly
"neilsolent" <neil@solenttechnology.co.uk> wrote in message
news:1160404022.242316.261870@i42g2000cwa.googlegroups.com...
As I understood it, a console is basically a device - it is the screen
when you are running a DOS prompt.
Yes, but the devil is in the details. The "screen" is actually a window
owned by NT's client server runtime system. It appeares to console programs
as though it were a device - i.e. ultimately an application calls
WriteFile() or WriteConsole() on its handle. The device's driver though
takes the text and does the equivalent of a DrawText() or TextOut()
operation on a windows device context.
Stdout is nothing more than a naming
convention - it is the "friendly" name of the handle to write output
to. Stdout could point to the console (if there is one) or a disk file,
or a tape drive, etc, etc. Given this, the lack of a console doesn't
seem to make any sense. I start the child process with stdout pointed
at a file, and it sort of half writes to it!
The C++ code I posted is actually part of a Windows service, so there
really is no console anyway??
Yours confused (but happier!),
Well, it's speculation without peeking at the source but I think that there
is a disconnect between what you want to do and how the DETACHED_PROCESS
flag is intended to work.
Without the flag, the loader and the operating system conspire to insure
that runtime device #1 (stdout) gets mapped to the Win32 handle
corresponding to the console.
On the other hand, the flag is presence is taken to mean that the
application does not in general do any output and if any is necessary it
will handle the allocation of a console device.
The no-flag case seems like the "natural" state of affairs to those of us
who grew up on C but you have to remember that it is not required that the
mapping actually be present in a Win32 executable. If you put a call to
printf() in a windowed application where you don't allocate a console and
you will see nothing because there is no device handle mapped to the stdout.
My _guess_ is that what is happening is that when you specify the
DETACHED_PROCESS that CreateProcess() ignores the output handle in the
start-up structure. This flag is intended to be used in the kinds of
applications that might be called services or daemons or symbionts. Perl
behaves just as a windowed application would - it goes through the motions
but the I/O fails because there is no mapping of a runtime I/O slot to an
operating system handle.
Who knows why "dir" is smart enough to have its output succeed? Not I. :-)
Regards,
Will