[PATCH v4] programs/winetest: don't create console when non connected to a console

[Eric Pouech]

Le 01/04/2022 à 17:27, Francois Gouget a écrit :
> On Fri, 1 Apr 2022, Eric Pouech wrote:
> [...]
>>> Do these consoles also appear on Windows then?
>>>
>> basically we should have the following hierarchy of processes (for a testbot
>> invocation)
>>
>>    testagentd Unix/windows
>>     \- TestLauncher (CUI)
>>        \- unit test (CUI)
>>           \- unit test can recurse upon itself (CUI)
> Almost. It's actually:
>     testagentd windows (DETACHED)
>     \- script.bat (cmd.exe -> CUI) -> creates a console
>        \- TestLauncher (CUI)
>           \- unit test (CUI)
>              \- unit test can recurse upon itself (CUI)
>
> So TestLauncher is actually started from a batch script: that's just
> because it's the easiest way to set environment variables like
> WINETEST_*. That functionality could be moved to TestAgentd if needed.
no that's fine, and IMO the way it should be...
>
>  From that point all processes reuse the script.bat console.
>
> Even if I manually test running user32_test.exe directly from
> TestAgentd, a console is created when user32_test.exe is started and
> the test succeeds.
>
> But if I modify TestAgentd so it uses DETACHED_PROCESS, then the console
> is only created when user32_test.exe forks, and then I get 2 failures
> on Windows:
>
> input.c:791: Test failed:  0 (a4/0): 00 from 00 -> 80 unexpected
> input.c:791: Test failed:  0 (a4/0): 41 from 01 -> 00 unexpected
yeah that's logical (testagentd tells it's child not to have a console, 
so it defers the console creation when a new process is created... hence 
the errors in input)
>
>
>
> On Unix the process is like this:
>
>     testagentd (Unix, no terminal)
>     \- shell script (sh Unix, no terminal)
>        \- WineTest.pl (perl Unix, no terminal)
>           \- ./wine TestLauncher (Windows CUI, no console)
>              \- unit test (Windows CUI) -> creates a console
>                 \- unit test can recurse upon itself (CUI)
>
> The './wine TestLauncher' step is replaced with './wine winetest.exe'
> for the daily full WineTest suite and for the mailing list patches.
>
> My understanding is that as long as the console window is started before
> the unit test 'main' starts it does not cause trouble. That seems to be
> how it works on Windows.
>
> So the fact we get failures in Wine seems to indicate that the console
> window is created after the unit test has started, so sorta
> asynchronously? Should that be considered to be a bug?
>
see below
>
>> TestLauncher is then created detached from unix but also windows
>> standpoint ;
> That's because testagentd being a Unix application it does a regular
> fork()+exec()? Should ./wine create a console for TestLauncher in such
> a case? Does that mean that ./wine should have an option or environment
> variable to specify whether that's desirable?
yes that's one of the questions ; using wineconsole would help here 
(even if not fully ok out of the box)
>
>
>> meaning the the w-console is only created for unit test.
>>
>> in both cases, the respawn from within the unit test should reuse the same
>> console
> That has me a bit confused.
> Doesn't that mean the console window exists before the unit test main()
> starts running? So why would it make a difference whether that console
> is created for TestLauncher or for the test unit?

[below]

we need to distinguish between:

- creation of the object console in wineserver (done synchronously at 
process startup)

- the user32 representation of that object (*) ; which is done 
asynchronously => hence depending on timing of creation of window/focus 
could impact tests (even if I don't have direct proof of that)

and as depicted above, cmd.exe is started on windows before TestLaunch, 
meaning full window realisation before the bat script is run... and the 
unit tests

while on wine, conhost is started in // of unit tests...

so moving console creation to TestLauncher creation could help, even if 
not 100% bullet proof

so the rendering of the console is always done in a (cmd.exe) window on 
windows ; in wine, it can be that way also, but also done by the unix 
tty when wine is started from unix command line

>
> [...]
>> from these considerations, I would recommand that we mimic windows' behavior:
>> when run under wine only, testagend should spawn TestLauncher with wineconsole
>> (we know we can force a user32/wine console creation):
>>
>> ./wine wineconsole TestLauncher... (instead of ./wine TestLauncher)
>>
>> François: what would be the best way to do it? (tweaking
>> platform_unix/platform_run() seems to be more widely used than just running
>> wine?
> That could be done by modifying the wine command that build/WineTest.pl
> uses. But my understanding from later emails is that this may not be
> desirable?

at this point yes

a) using wineconsole doesn't support out of box the redirections needed 
by TestLauncher

b) it can be put on hold for now, until we're sure that moving 
everything to GUI is doable and acceptable


thanks for looking into it

>
> --
> Francois Gouget <fgouget at codeweavers.com>