winmm: MCI system commands are not eligible for auto-open. (try 2)

[Joerg-Cyril.Hoehle at t-systems.com]

Dmitry Timoshkov wrote:

>Since there is no neither todo_wine statements in the tests, nor test failures
>under Wine that means that both the tests and the patch are not OK.

What has Wine to say when talking about the correctness
of tests?  Only native dictates what the test result should be.
The emerging rule is: "no notification in case of error", and there's even a
specific test case about the MCI sound string command in the tests.

I believe you forgot that AJ mentioned a notification test failure that
appeared with "try 1": So there was a test failure under Wine.

>> b) There was no need for todo_wine in the past because this double error could
>>    not be detected.  No notification was and is the correct behaviour when the
>>    sound command returns an error, as it currently does.
>Then that's what you need to fix in the first place.

I cannot demonstrate the value of a fix to MCI_SOUND via a test case if the parser
never calls MCI_SOUND.  That's why the order in my git tree and that of submission is:
1. Get MCI_SOUND called (and fix the notification because of
   the test failure this introduces).
2. Get MCI_SOUND to actually play a sound (in my queue, past the 64bit patch).

I find it illogical to write a patch that would prefix an existing test
with todo_wine.  I aim at eliminating existing todo_wine.

Now I think the subject of my patch is misleading.  It should have read
"winmm: Correctly deal with MCI system commands." (to some extent).

Regards,
 Jörg Höhle.