Le 15/03/2022 à 22:56, Jacek Caban a écrit :
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 ;)
one simple fix is to add DETACHED_PROCESS to creation_flags in start.exe when parsing /exec command line option and not being attached to a console
A+