Ross Ridge wrote:
> Mark Mitchell wrote:
>> The new pex-win32.c code doesn't operate correctly when used for
>> MinGW-hosted tools invoked from a Cygwin window. In particular, process
>> creation ("gcc" invoking "as", say) results in a DOS console window
>> popping up. When invoked from a DOS window, things are fine.
>
> What sort of "Cygwin window" are you talking about? Cygwin bash running
> in a normal Windows console window, or an rxvt or xterm window?
The latter.
>> The reason for this problem is that the current code uses MSVCRT's spawn
>> to create the process, and that function doesn't provide fine enough
>> control. You have to use CreateProcess to make this work as desired.
>> When invoking CreateProcess, you must set bInheritHandle to TRUE and
>> pass a long a STARTUPINFO structure with dwFlags set to
>> STARTF_USESTDHANDLES, and the various hStd* handle fields set to the
>> values from the calling process.
>
> Setting bInheritHandle to TRUE causes the newly created process to
> inherit all of its parent process's inheritable handles. There's no
> point in using the STARTUPINFO structure to specify handles for stdin,
> stdout, and/or stderr unless you're changing them. Since MSVCRT's spawn
> sets bInheritHandle to TRUE, I don't see what difference this would make.
>
> 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.
Exactly -- there is no parent console window here. 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.
Empirically, if you do not set CREATE_NO_WINDOW dwCreationFlags, a
console appears, which is undesirable. 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.
Unfortunately, I've also just found that setting CREATE_NO_WINDOW means
that the child's standard output/error do not appear when run from a
console. Perhaps we have to actually check whether we already have a
console before we can know how to invoke CreateProcess.
> Either gcc is somehow losing
> it's console window or it never had one to begin with. Hmm... if that
> "#!" kludge is being used here then it could be the shell that's losing
> the console.
No, it's not that.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
