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?
sigh... running TestLauncher in wineconsole will not work out of the box.. since testagentd currently does 'wine TestLauncher cmd args > foo', so we would need to change also wineconsole to redirect the streams in subprocess
One other solution that we may consider is to build tests as GUI applications and add AttachConsole(ATTACH_PARENT_PROCESS) to main() in test.h. That should preserve desired behaviour. We'd probably need an opt-out mechanism for console tests, but it should be fine otherwise, unless I'm missing something.
maybe...
a) we have to check for every test that moving to gui will not break (more) things <g>
b) actually I wonder if the console attachment is needed at all (in most of the cases, the std handles would suffice) (console tests apart of course)
to demonstrate: simple run on user32/tests:input
- yesterday from Rémi: https://testbot.winehq.org/JobDetails.pl?Key=111683
- today, with user32_test.exe regenerated as gui (no other tricks): https://testbot.winehq.org/JobDetails.pl?Key=111744&f101=exe64.report&am...
(cannot tell where unique failure under windows comes from, but looks way better, perhaps not perfect)
A+