On Fri, 29 Jan 2016, Henri Verbeet wrote:
On 29 January 2016 at 00:54, Francois Gouget fgouget@codeweavers.com wrote:
There is a set of traces showing WaitForInputIdle() being replaced with our own implementation: shlexec.c:2318: Hooked USER32.dll.WaitForInputIdle
And then traces showing our implementation being called: shlexec.c:2258: WaitForInputIdle() waiting for dde event
Except that on Windows 10 we never get the second set of traces which means we failed to override WaitForInputIdle().
I'm hardly an expert on shell32, but any chance the hooking worked fine and WaitForInputIdle() is just not getting called? Would explicitly specifying SEE_MASK_WAITFORINPUTIDLE make it any better?
Thanks! I had not seen this option. Also it should really not be needed but it does solve the problem on Windows 10... and kinda breaks the tests on Vista to Windows 8.
https://testbot.winehq.org/JobDetails.pl?Key=20082
To wit:
* DDE implies doing a WaitForInputIdle(). So Windows 10 should really be doing it without being told, just like all the previous Windows versions before it.
* But we also know that WaitForInputIdle() does not work on console applications like our confomance tests. So maybe Windows 10 detects the target executable is a console application and skips this call. It's either that or assuming DDE is totally broken on Windows 10 which seems unlikely (maybe I'll test it at some point).
* On all versions from Vista to Windows 8.1, adding SEE_MASK_WAITFORINPUTIDLE causes WaitForInputIdle() to be called twice when DDE is involved. This further 'proves' that this flag should not be needed.
* This is why the flag breaks our tests: unlike the real implementation our WaitForInputIdle() replacement blocks every time it is called. Fortunately that's a simple fix.
* On Windows XP and 2003, even with the extra flag, WaitForInputIdle() is called only once.
* It would really be better to do our DDE tests with a GUI target application. I have no idea how to do that though.