this 'next' - aka third - patch, just creates a window less console in some cases for an initial process and should fix (or at least improve) a couple of open bugs
(to make it short, in scenario like "wine foo >& log < /dev/null", it prevents foo and the subprocesses when in cui subsystem to create visible consoles)
(just to share it here)
To recap our private conversation, there are nice things about that solution: it makes such invocation more similar to a more common situation on Windows and I like that aspect. My main concern is that it will make invoking Wine in situations when there is no Unix console available much more expensive, because we'd need to create an extra conhost process that would be useless in majority of cases. I know that we have some users using Wine as part of their Unix scripts, likely ran in the background, for whom it's likely to provide worse performance due to need to create twice as many Wine processes. It may not be a deal breaker, but I think it's a concern that we should consider.
One possible solution to that would be, for example, to have something like CONSOLE_HANDLE_SHELL_NO_WINDOW, which would be inherited by CreateProcess(0) and prevent from creating an actual new console. This would achieve most of this patch's goals with lower runtime price.
Other possible solution is more specific to Wine tests, which are causing most of those problems. We could just build tests as GUI applications and avoid the problem in the first place. It's not a general solution, through. We could maybe have wineconsole --no-window option that, instead of using AllocConsole, would use CREATE_NO_WINDOW. This would essentially give user an opt-in option to achieve the same outcome as your patch.
Anyway, none of above is perfect. I just thrown more ideas to the pool, hoping for your and/or other's opinions.
I think that the root of the problem is that there is no single right thing when Wine is invoked by Unix process with no Unix console available (when Unix console is available, the choice to use it is mostly uncontroversial). In some cases, creating a console window is desired, while for others it's not. Currently user is able to force console window creation by running explicitly wineconsole, but the opposite is not possible under assumption that "default" is good for other cases. This is an equivalent of creating the process with DETACHED_PROCESS on Windows.
anyway it would be interesting to have a tool (say wineconsole) where we could launch a wine binary with a given console setup (=detached, =window, =no-window...); optinonaly, it should also take care of redirection of unix std handles (and pass them to subchild)... that would require another flag (like --std-inherit). this would allow to have an answer to any specific need
I'm all against moving wine tests to GUI subsystem... it doesn't solve the bottom line issue: windows "regular" behavior is that CUI processes are attached to a console...
yet to decide what's the best option
- for Wine's default for initial process not connected to a unix tty
- for testbot
I'll wait for this to be settled before zero:ing ConsoleHandle for GUI processes...