This is part of a larger change to behave as native regarding inheriting (or not) the std handles in CreateProcess [1].
We have a couple of Wine programs (regsvr32, uninstaller, winecfg, wscript...) which are compiled in the GUI subsystem (as their native counterparts are), but still requires output in unix console when run from it.
Since we no longer inherit console handle for GUIs, this output of unix console is broken (when run from command line using start.exe) (see https://bugs.winehq.org/show_bug.cgi?id=55723).
The goal of [1] is to zero the inherited std handles in CreateProcess for a child in GUI subsystem as native does. Not doing it create other problems (see https://bugs.winehq.org/show_bug.cgi?id=55439 for example).
I tried several options to handle this (also considering something that would be consistent will all the changes in [1]).
I considered several options:
* if initial process is in GUI subsystem, create a handle around fd 1 and don't create a unix console. That would work when not using start.exe. But if child has to be run with start.exe, the standard inheritance of std handles bound to unix console won't work (std handles to console are zero:ed out for GUI, see tests in [1]), so the solution would be to, in start.exe: bind unix fd 0,1,2 to handles and pass them in start.exe's CreateProcess; but only if child is GUI (if CUI we still want to keep unix console inheritance). Doable, but potentially ugly. * use AttachConsole(ATTACH_PARENT_PROCESS) in regsvr32. This works well when run with start.exe, but fails when run without (as process has no parent). This would require detecting this case of failure in AttachConsole() and fall back to creating a new unix console. An alternative would be to launch every program in CUI subsystem with start.exe. But I'm not sure we want this. * so I ended up simply reopening fd 1 (and others if needed) in regsvr32. This has the advantage of keeping ntdll and start.exe behavior as close as possible at what native does, and put the burden on each program.
Comments welcomed.
That fix shall be applied on all the Wine programs in GUI subsystems requesting I/O with unix console.
[1] https://gitlab.winehq.org/epo/wine/-/tree/mr-console?ref_type=heads