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

[Francois Gouget]

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.

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



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?


[...]
> a) when the console is created
> 
> under Windows, the console is created when TestLaunched is spawned. Seems
> logical: first CUI process, testagentd is likely run detached.

Modulo the extra cmd process, yes.


> in wine env, the console is created at least for the unit test (test as
> written cannot get information from testlauncher back)
> 
> as testagentd (on unix) is likely detached (from unix tty),

On Unix testagentd is started by systemd on boot. So you are right, it 
does not have a terminal.


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


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

[...]
> 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?

--
Francois Gouget <fgouget at codeweavers.com>