Must multimedia players check the message queue and invoke DispatchMessage?

[Juan Lang]

Hi Joerg,

> 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?

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