Alexandre Julliard wrote: > "Maarten Lankhorst" <[EMAIL PROTECTED]> 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.