[PATCH 2/2] kernelbase: Add support for CREATE_NO_WINDOW flag.

[Eric Pouech]

>
>> 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...