This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with pex-win32.c


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
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]