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

[Akihiro Sagawa]

Hi Jörg,

On Tue, 2 Jun 2015 14:04:48 +0200, Joerg-Cyril.Hoehle wrote:
> >However, recent Windows systems don't allow to call MCI commands from another thread.
> Could you please elaborate? I understand the Co/UnCo issue, but what about other commands?
> Wouldn't the thread invoking Co/UnCo remain strictly internal to winmm?
>
> At the MCI string command level, all you see are "device" numbers and aliases, so
> why shouldn't an app be allowed to send "status x position" from any thread in
> the app's address space?

Essentially, it should.  But, please see
https://testbot.winehq.org/JobDetails.pl?Key=13867 and its patch.
In the test, it opens tempfile.wav with alias mysound in mci_open_thread
and plays mysound in mci_another_thread.  It also expects the latter
attempt is failed with MCIERR_INVALID_DEVICE_NAME.
In the main thread, mciGetDeviceID's return value is zero which means an
error.  This indicates the device doesn't exist in winmm level.
Finally, it succeeds to open a file with the same alias in main thread.
The result shows there are no errors at these points.

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.
I'll continue investigating old Windows behavior.

Regards,
Akihiro Sagawa