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