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