No subject

If since w2k calls like midiStreamRestart() and midiStreamOut() are not
asynchronous messages to a concurrently running player and instead drive the
player loop on the calling thread (=3D the application one's), then I can i=
magine
a whole class of programs that worked on w9x but hang on newer systems -- e=
.g.
Heroes, says comment #18.
Not all programs would hang though, those designed around message dispatchi=
ng
delivered to the app's message queue have a good chance of working with
recursive invocations of Wait/Peek/DispatchMessageA() by a winmm player
executing in the application's thread.

As far as Wine is concerned, I'd favour the w9x behaviour: have the multime=
dia
players sit in their own thread, even though a proper design causes me
headaches with concurrency and locking issues.


Under this perspective, it looks like an error when player loops that execu=
te
synchronously in the app's thread (like all MCI players, e.g. MCIAVI) never
drain and DispatchMessageA() the app's message queue -- the app may dead-lo=
ck
when expected callbacks are not invoked.  Is this perhaps an explanation to=
 the
bugs listed in bug #21060, comment #2?

--=20
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=3Demail
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.=