[PATCH v4] programs/winetest: don't create console when non connected to a console
Eric Pouech
eric.pouech at orange.fr
Fri Apr 1 08:26:58 CDT 2022
>> 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&f201=task.log#k201
(cannot tell where unique failure under windows comes from, but looks
way better, perhaps not perfect)
A+
More information about the wine-devel
mailing list