This is the mail archive of the
mailing list for the GCC project.
Re: Problem with pex-win32.c
- From: rridge at csclub dot uwaterloo dot ca (Ross Ridge)
- To: gcc at gcc dot gnu dot org
- Date: Fri, 10 Mar 2006 18:22:08 -0500 (EST)
- Subject: Re: Problem with pex-win32.c
Ross Ridge wrote:
> I think you're barking up the wrong tree here. Windows only creates
> console windows automagically when a console application starts that
> can't inherit its parent's console window.
Mark Mitchell wrote:
> Exactly -- there is no parent console window here.
Why isn't there a console window? The Cygwin version of rxvt, and I
think xterm, creates (and keeps hidden) a console window that should
be inherited by gcc and as. If there wasn't console window for gcc to
inherit, why didn't Windows create one for gcc?
Maybe gcc was linked with -mwindows. That would cause gcc not have
console window, neither an inherited one nor an automagically created one,
and so one would have be created for the invoked tools.
> Hence, we need the child (which is a console application) created
> without a console window, but with its standard input/output connected
> to its parent.
More precisely, the child should inherit its standard input and output
handles from its parent.
>Empirically, if you do not set CREATE_NO_WINDOW dwCreationFlags, a
>console appears, which is undesirable.
Using CREATE_NO_WINDOW really isn't an option here because it's not
supported by Windows 9x/ME.
> However, if you do set CREATE_NO_WINDOW, but do not set the standard
>handles in the STARTUPINFO structure, the child's standard output/error do
>not appear anywhere; perhaps they are closed because there is no console.
With CREATE_NO_WINDOW the new process has no attached console. Like a
-mwindows application, it neither inherits one, nor is one created for it.
Since a process can't use a console other than the one attached to it,
there's nowhere for the output to go to.