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