Currently, for many applications the generic Wine icon
or a class default icon is used in window manager caption
or taskbar instead of the application icon set with WM_SETICON.
See, for instance, Bug 3370.
What actually happens is this: the application icon is
correctly set when processing WM_SET
three expected defwinproc
messages coincide with three actual non-defwinproc messages
which are expected later-on. Thus this failure is actually
not about messages sent from incorrect place, but simply
about missing messages which is a very typical failure
among the todo tests.
Cheers,
Juris Smotrovs
In an attempt to solve bug 4964, I found several issues
where Wine behaves incorrectly (e.g. not sending the messages
it should send) or simply differently (e.g. not sending
messages where Windows sends them, but perhaps there is no
real reason in Wine case to send them) than Windows
during window
