[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