Visual studio 6 build fix.

[Rein Klazes]

Hi,

MS Visual C++ v6, when invoking the compiler and other build tools does
the following:

create anonymous pipe;
 duplicate the pipes write handle;
 open's the file NUL

calls CreateProcess starting vcspawn.exe with:
    startup info iohandles set to the 3 handles obtained above;
    the startup info flag STARTF_USESTDHANDLES set;
    create flag CREATE_NEW_CONSOLE set.

the parent process reads from the pipe, and analyses the compiler and
other messages that are obtained that way.

Wine's console startup code is not really expecting this and insists on
creating new stdio handles instead of inheriting them.

The attached patch makes this work properly.

Changelog:
    server	: process.c
    dlls/kernel	: console.c
    A starting process must obey the STARTF_USESTDHANDLES flag, even
    it is starting a new console.

Rein.

[Alexandre Julliard]

Rein Klazes  writes:
> @@ -210,7 +212,12 @@ static int set_process_console( struct p
>      if (process->create_flags & CREATE_NEW_CONSOLE)
>      {
>          /* let the process init do the allocation */
> -
>    return 1;
> -
>    /* unless the startup info specifies to use */
> -
>    /* the io handles in the startup info */
> -
>    if( !info || !info->data ||
> -
>            !((((RTL_USER_PROCESS_PARAMETERS *)info->data)->dwFlags) &
> -
>                STARTF_USESTDHANDLES))
> -
>        return 1;

The server must not know about the process parameters structure, the
STARTF_USESTDHANDLES flag has to be handled on the client side.

[Rein Klazes]

On 10 Dec 2004 15:14:30 +0100, you wrote:
> Rein Klazes  writes:
> > @@ -210,7 +212,12 @@ static int set_process_console( struct p
> >      if (process->create_flags & CREATE_NEW_CONSOLE)
> >      {
> >          /* let the process init do the allocation */
> > -
> >    return 1;
> > -
> >    /* unless the startup info specifies to use */
> > -
> >    /* the io handles in the startup info */
> > -
> >    if( !info || !info->data ||
> > -
> >            !((((RTL_USER_PROCESS_PARAMETERS *)info->data)->dwFlags) &
> > -
> >                STARTF_USESTDHANDLES))
> > -
> >        return 1;
>
> The server must not know about the process parameters structure, the
> STARTF_USESTDHANDLES flag has to be handled on the client side.

Is this one acceptable?

If there is still a problem, then I need more hints to what is needed.

Rein.

[Eric Pouech]

> Is this one acceptable?
>
> If there is still a problem, then I need more hints to what is needed.

the only part which is questionnable is as follows:
- what happens (in your case) if the child (after being run through all the 
init) calls FreeConsole and then AllocConsole?
- I don't know the answer. The patch will let the new standard handles be still 
the ones the child as inherited, while it could be the ones allocated by 
AllocConsole.
I don't know the answer for sure (my wild guess would be the second), but that 
requires testing (and a proper test case for winetest wouldn't hurt of course).
If I'm right, then you should keep AllocConsole as it is and in 
dlls/kernel/kernel_main.c set the default handles to what's inherited after 
calling AllocConsole
A+

[Rein Klazes]

On Sun, 12 Dec 2004 14:02:54 +0100, you wrote:
> > Is this one acceptable?
> >
> > If there is still a problem, then I need more hints to what is needed.
>
> the only part which is questionnable is as follows:
> - what happens (in your case) if the child (after being run through all the
>
> init) calls FreeConsole and then AllocConsole?
> - I don't know the answer. The patch will let the new standard handles be still
>
> the ones the child as inherited, while it could be the ones allocated by 
> AllocConsole.
> I don't know the answer for sure (my wild guess would be the second), but that 
> requires testing (and a proper test case for winetest wouldn't hurt of course).
> If I'm right, then you should keep AllocConsole as it is and in 
> dlls/kernel/kernel_main.c set the default handles to what's inherited after 
> calling AllocConsole

That makes sense. I will have a look into it.

Rein.

[Rein Klazes]

On Sun, 12 Dec 2004 14:02:54 +0100, you wrote:
> > Is this one acceptable?
> >
> > If there is still a problem, then I need more hints to what is needed.
>
> the only part which is questionnable is as follows:
> - what happens (in your case) if the child (after being run through all the
>
> init) calls FreeConsole and then AllocConsole?
> - I don't know the answer. The patch will let the new standard handles be still
>
> the ones the child as inherited, while it could be the ones allocated by 
> AllocConsole.
> I don't know the answer for sure (my wild guess would be the second), but that 
> requires testing (and a proper test case for winetest wouldn't hurt of course).
> If I'm right, then you should keep AllocConsole as it is and in 
> dlls/kernel/kernel_main.c set the default handles to what's inherited after 
> calling AllocConsole

Eric,

Testing on Win2K:

If I do a FreeConsole() & AllocConsole() in a child that has obtained
stdio handles from the StartupInfo struct, I get exactly the same
handles. Even the CREATE_NEW_CONSOLE flag is irrelevant. In contrast, if
the handles are just inherited (no STARTF_USESTDHANDLES flag), I get new
handles directed to the new console.

So, with luck, I think my approach seems the correct one.

Resubmitting, with minor cleanups.

Changelog:
    server	: process.c
    dlls/kernel	: console.c
    A starting process must obey the STARTF_USESTDHANDLES flag and
    use the standard io handles from the StartupInfo structure, even
    it is starting a new console.

Rein.