https://bugs.winehq.org/show_bug.cgi?id=38241
--- Comment #6 from Andrew Eikum aeikum@codeweavers.com --- Created attachment 54385 --> https://bugs.winehq.org/attachment.cgi?id=54385 winmm/tests: MCI rejects commands from threads that didn't open the device
(In reply to Sagawa from comment #1)
Created attachment 51049 [details] proposed patch
From my inspection, this is MCI Mpegvideo driver, mciqtz32's issue. Generally, mci "open" and "close" can call in different threads for the same device. Therefore, the following case triggers 'CoUninitialize Mismatch' in the current implementation.
- thread A, open foo.mp3 with MPEGVideo driver. i.e. 'open foo.mp3 alias
foo type MPEGVideo'. MCIQTZ_mciOpen() silently calls CoInitialize() for thread A. 2. thread A, play foo. 3. thread B, close foo. MCIQTZ_mciClose() implicitly calls CoUnintialize() for thread B though the thread is not initialized.
Attached proposed patch introduces a task thread to avoid above situations, and DriverProc passes the arguments to the thread.
Some tests indicate this is wrong. MCI seems to reject commands from the thread that didn't open them with MCIERR_INVALID_DEVICE_NAME. See attached tests, run here:
https://testbot.winehq.org/JobDetails.pl?Key=22738