Alexandre Julliard wrote:
"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.
I remember sending the patch for this exact thing a while back, which you of course refused under the same pretense - showing a real life app that depends on it. So if tests are not a real life app that shows a difference between Wine and windows - then why do we bother with Wine at all? At least should change the moto to "might run some apps with loads of problems and never be 100% compatible".
One for sure will find an app that in one way or another depends on undocumented windows behavior. So if a test can be written to show a difference between Wine and windows. Then this difference should be fixed in Wine.
Vitaliy.