Hi Joerg,
- 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?
Are you concerned about the applications introducing deadlocks by not servicing messages quickly enough, or about MCI introducing deadlocks by not processing messages in the current thread?
If the former, I'd say that it's possible that Microsoft would consider this to be a buggy app, and not an issue for us. It's common to require that applications continue to "pump" the message loop when calling some blocking function. Modal dialog boxes continue to do so, for example.
If the latter, this probably requires that MCI pump the message loop while it's processing.
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?
Perhaps call SetTimer with a period shorter than the duration of something you're about to play, and show that the thread receives a WM_TIMER before playing is complete?
Would the obligation to service messages disappear if the players ran in their own thread (like w9x seems to do)?
The obligation to process messages within MCI? Possibly. Since nothing since Win9x seems to use threads, however, I wouldn't be surprised if some app expects that it can post messages from its callbacks. In other words, don't expect all applications to be "Win9x safe."
Hope that helps, --Juan