Hello Alexandre,
2008/3/30, Alexandre Julliard julliard@winehq.org:
"Maarten Lankhorst" m.b.lankhorst@gmail.com writes:
Or wine is doing something wrong. After some more digging I found that SetLastError() was set to 0 by TlsGetValue when called from X11DRV's MsgWaitForMultipleObjectsEx. After I tried fixing this so that SetLastError is only set when NULL is returned, one of the other tests miraculously started working inside a todo block too (cursoricon). I'll work on some testcases to verify that tlsgetvalue only calls SetLastError(0) when succesfully returning null.
In most cases it's the test that is doing something wrong by being too strict. We don't care whether last error is modified or not on success, and there's no reason to test for it, unless it's one of the very few functions that do something special on success, or unless there is a real app that depends on it.
Well, EnumWindows encourages applications to use setlasterror to set an error message to pass a return value. Suppose if I took this approach, and then called SendMessageTimeout from my enumeration function, the last error would be useless because it's overwritten. Adding a few lines to SendMessageTimeout confirms this behavior: Windows doesn't overwrite the last error by default. I tracked where it does timeout to that tlsgetvalue call in MsgWaitForMultipleObjectsEx, which doesn't currently have last error tests. I assume it doesn't change last error unless it returns null and has success. This would fix SendMessageTimeout to act more like windows and my BroadcastSystemMessage implementation.
And regarding 'there is no real life app that depends on it', too often I find obscure problems with applications because wine does something slightly different then windows does...
Cheers, Maarten.