user32: Implement BroadcastSystemMessage, try 5.1

[Maarten Lankhorst]

Hello Alexandre,

2008/3/30, Alexandre Julliard <julliard at winehq.org>:
> "Maarten Lankhorst" <m.b.lankhorst at 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.