Hi,
While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=20058
Your paranoid android.
=== w1064 (32 bit shlexec) === shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2391: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt4CE4.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt4CE4.tmp\test file.sde")]' shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2
=== w1064 (64 bit shlexec) === shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2
On Thu, 28 Jan 2016, Marvin wrote: [...]
=== w1064 (32 bit shlexec) === shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2391: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt4CE4.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt4CE4.tmp\test file.sde")]' shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2
=== w1064 (64 bit shlexec) === shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2 shlexec.c:2379: Test failed: failed: rc=29 err=2
These are the usual Windows 10 DDE ShellExecute() failures. What's interesting is that I think the extra traces point to the reason for these failures. Unfortunately I don't know how to fix it.
The extra traces (and a bit more) can be seen here: https://testbot.winehq.org/JobDetails.pl?Key=20056&log_207=1#k207
* 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().
Why override WaitForInputIdle()? Here it is from the source:
* WaitForInputIdle() will normally return immediately for console apps. * That's a problem for us because ShellExecute will assume that an app * is ready to receive DDE messages after it has called * WaitForInputIdle() on that app. To work around that we install our * own version of WaitForInputIdle() that will wait for the child to * explicitly tell us that it is ready. We do that by changing the * entry for WaitForInputIdle() in the shell32 import address table.
Does anyone know why hooking WaitForInputIdle() had no effect on Windows 10?
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?
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.
-
Francois Gouget -
Henri Verbeet -
Marvin