Hi,
In Bug #3930 http://bugs.winehq.org/show_bug.cgi?id=3930#c41 I conjectured that:
1. Since w2k, winmm hijacks the application's thread to play multimedia content. Wine does this as well with MCI_WAIT, but it should as well affect winmm:playSound, winmm:midi* and winmm:wave*.
2. Consequently, the players must implement a message loop and dispatch regular window messages using DispatchMessageA/W Currently, Wine does not. This IMHO has potential for dead locks. Music and animations can play for a long time and messages ought to be serviced.
I'm not familiar with windows messages at all. What do you think about the consequence?
Point 1 explains why tests reveal the current thread as the one executing all callbacks but one since w2k.
Point 2 should be testable by playing a long piece of video or music and prequeuing or injecting (how?) some windows events. How to test this in a convincing manner?
Would the obligation to service messages disappear if the players ran in their own thread (like w9x seems to do)?
Thanks for your help, Jörg Höhle