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

[Jacek Caban]

Hi Eric,

On 4/6/22 11:57, Eric Pouech wrote:
>
>> 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


Sure, I think that we can be much more flexible about wineconsole 
itself, so that sounds fine to me.


>>
>> 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...
>>
>>
> that patch might work instead
>
> - at least, with it, testbot seems happier on user32:input 
> (https://testbot.winehq.org/JobDetails.pl?Key=112035&f101=task.log#k101)
>
> - applies on top of the two previous patches
>
>
> in terms of performance, I measured locally:
>
> 4 different settings:
>
> - when starting attached to a unix console
>
> - when starting not attached to a unix console (current wine tree)
>
> - when starting not attached to a unix console (current wine tree + 
> ALLOC_NO_WINDOW for initial process)
>
> - when starting not attached to a unix console (current wine tree + 
> SHELL_NO_WINDOW for initial process = the attached patch)
>
>
> three measures:
>
> ==============
>
> in all measures, using time on running tasklist.exe (which only does a 
> couple of FIXME:s; so a proxy for process startup time - and tear down)
>
> done on bare metal, with a relatively idle machine with "decent" 
> #procs and memory... so values to be seem as best case, heavier work 
> load might increase the differences
>
>
> measure #1:
>
> starting a new wine session: start done 10 times (waiting in between 
> for wineserver to shut down; with warm up to fill fs caches)
>
>      |            | /w patch        | full session init |
>      |------------+-----------------+-------------------|
>      | Unix shell |                 | 166.3 ms          |
>      | no shell   |                 | 163.7 ms          |
>      | no shell   | alloc_no_window | 166 ms            |
>      | no shell   | shell_no_window | 164 ms            |
> roughly, a slight degradation when starting up conhost.exe ; no 
> measurable difference when not attached to a unix console
>
> measure #2:
>
> keeping an active wine session, starting 1000 times tasklist in a row
>
>       |            | /w patch        | incremental start |
>       |------------+-----------------+-------------------|
>       | Unix shell |                 | 9,440 ms          |
>       | no shell   |                 | 7,903 ms          |
>       | no shell   | alloc_no_window | 9,271 ms          |
>       | no shell   | shell_no_window | 7,951 ms          |
> so a 15 to 20% impact on process startup... shell_no_window doesn't 
> show measurable difference from current situation for non attached 
> processes
>
> measure #3
>
> same logic as measure #2, using start.exe in the middle
>
>       |            | /w patch        | incremental start |
>       |------------+-----------------+-------------------|
>       | Unix shell |                 | 38.315 ms         |
>       | no shell   |                 | 31.945 ms         |
>       | no shell   | alloc_no_window | 38.472 ms         |
>       | no shell   | shell_no_window | 32.428 ms         |
> confirms reasults of measure #2, but with a huge impact of start.exe 
> (path lookup...)


Thanks, those results are interesting. I must admit that I expected 
bigger difference (like time x2).


Given how simple the solution that you attached is, I'm biased towards 
choosing it. If you're happy if that, I'd say let's use it. One note 
about it, through, new_process server request uses "> 3" check to decide 
if it should use duplicate_handle() on passed handle, which does not 
work well with CONSOLE_HANDLE_SHELL_NO_WINDOW being 5. Maybe we should 
use -1, -2, ... for magic handles instead.


Thanks,

Jacek