mciqtz32: Guarantees that CoInitialize and CoUninitialize run on the same thread.

Joerg-Cyril.Hoehle at Joerg-Cyril.Hoehle at
Tue Jun 9 09:42:36 CDT 2015


Akihiro Sagawa wrote:
> > >However, recent Windows systems don't allow to call MCI commands from another thread.
> In the test, it opens tempfile.wav with alias mysound in mci_open_thread and plays mysound in
> mci_another_thread.

> To wrap up, "device" and alias is not visible between threads.
> Among testbot, this is true. Additionally, my test shows it's true for Windows NT 4, but false for Windows 98.

Good catch. This is news to me. Long ago I observed that devices are not visible
across processes (IIRC I opened 2 DOS command windows on a w95 system) but
had no reason to doubt the Wine thread visibility code that I saw.

"Invisibility across threads" confirmed on a real w2k machine (not doubting your test
result, it's just so surprising). I'll test a w95 machine another time. Note that
I doubt that the winmm mci test still works on w95. IIRC, "play mine.wav"
only plays once on a w95 box, because the w95 MCI system appears to switch to C:
afterwards. I can't remember whether the test works if you start in C:.

Older winmm mci tests in git worked on w95, but as I added more tests, I choose not
to care about w95 behaviour and targeted w98 instead, which behaved much better.
I vaguely remember that it was easy to cause w95 to hang with added mci/winmm tests,
whereas w98 and ME worked well. So I defined w98 as the ideal platform for ancient games.

>but false for Windows 98
Hmm, I really don't know whether Wine should follow w2k/wxp/w7 behaviour here
(still assuming that it's old games that use the MCI). I'm really
surprised to learn that MS has changed the behavior that radically.
OTOH, perhaps there's no issue? W3.x and w9x apps would never(?) use threads,
(the "cooperative multitasking experience" mind set) so they won't notice a change?

	Jörg Höhle

More information about the wine-devel mailing list