[PATCH v3 5/5] dlls/ntdll: allocate a console for initial CUI process when not attached to a Unix console

[Jacek Caban]

Hi Eric,

On 2/17/22 10:10, Eric Pouech wrote:
> suggested by Jacek Caban
>
> Signed-off-by: Eric Pouech <eric.pouech at gmail.com>
>
> ---
>   dlls/ntdll/unix/env.c |    2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/dlls/ntdll/unix/env.c b/dlls/ntdll/unix/env.c
> index c7e0674e083..a69d0f26e87 100644
> --- a/dlls/ntdll/unix/env.c
> +++ b/dlls/ntdll/unix/env.c
> @@ -1657,6 +1657,8 @@ static void get_initial_console( RTL_USER_PROCESS_PARAMETERS *params )
>       wine_server_fd_to_handle( 1, GENERIC_WRITE|SYNCHRONIZE, OBJ_INHERIT, &params->hStdOutput );
>       wine_server_fd_to_handle( 2, GENERIC_WRITE|SYNCHRONIZE, OBJ_INHERIT, &params->hStdError );
>   
> +    params->ConsoleHandle = CONSOLE_HANDLE_ALLOC;
> +
>       /* mark tty handles for kernelbase, see init_console */
>       if (params->hStdInput && isatty(0))
>       {


Looking more at this, I'm not sure if it's a good idea, at least in its 
current form. There are situations where user would not want the console 
to be created. For example, user may have a Unix script that runs some 
non-interactive Windows commands with Wine, which is not attached to any 
console. I guess that some heuristic like if (!params->hStdInput && 
!params->hStdOutput) should mostly catch such cases, but it's still not 
perfect. I guess users could still use something like "start /b" to be 
explicit, but it's not obvious if it's worth it.


BTW, I noticed that start.exe CREATE_NEW_CONSOLE handling will not be 
right with your patches. "/b" option should probably use DETACHED_PROCESS.


Thanks,

Jacek