[PATCH v4 5/5] dlls/kernelbase: handle corner case in CreateProcess

[Jacek Caban]

Hi Eric,

On 2/21/22 08:34, Eric Pouech wrote:
> diff --git a/dlls/kernelbase/process.c b/dlls/kernelbase/process.c
> index 35381f409e9..1cecbce9321 100644
> --- a/dlls/kernelbase/process.c
> +++ b/dlls/kernelbase/process.c
> @@ -191,7 +191,11 @@ static RTL_USER_PROCESS_PARAMETERS *create_process_params( const WCHAR *filename
>   
>       if (flags & CREATE_NEW_PROCESS_GROUP) params->ConsoleFlags = 1;
>       if (flags & CREATE_NEW_CONSOLE) params->ConsoleHandle = CONSOLE_HANDLE_ALLOC;
> -    else if (!(flags & DETACHED_PROCESS)) params->ConsoleHandle = NtCurrentTeb()->Peb->ProcessParameters->ConsoleHandle;
> +    else if (!(flags & DETACHED_PROCESS))
> +    {
> +        params->ConsoleHandle = NtCurrentTeb()->Peb->ProcessParameters->ConsoleHandle;
> +        if (!params->ConsoleHandle) params->ConsoleHandle = CONSOLE_HANDLE_ALLOC;
> +    }
>   
>       if (startup->dwFlags & STARTF_USESTDHANDLES)
>       {


I'm still a bit concerned about inconsistency this will bring due to how 
we conditionally use start.exe when Wine is launched by a Unix process. 
To give you an example, assume that we're not attached to Unix console 
and gcc.exe is a 32-bit console application accessible by Windows PATH:


# Wine will lunch gcc.exe directly, so it will not bring a new console 
window; that's fine:

wine path/to/gcc.exe


# start.exe will case a new console window, because gcc needs to be 
looked up:

wine gcc


# start.exe will cause a new window, because of 32/64 mismatch:

wine64 path/to/gcc.exe


Maybe we could set PEB console handle to some non-zero invalid value 
when load_start_exe() is used. This would make it consistent, but better 
ideas are welcomed ;)


Thanks,

Jacek