winmm: The "open new ..." MCI string command sets an empty OPEN_ELEMENT.

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

Hi,

I was surprised to discover that I had missed that flag at the time when I closely looked at the MCI parser,
despite my note in winmm/tests/mci.c about "open new" mapping to a zero-length ElementName.
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winmm/tests/mci.c#l184

My mciseq rewrite needs the correct handling, because it is getting very compatible with native.
Unlike other Wine mci* drivers, it manages to distinguish the 3 modes of operation:

 1 open foo.ext ...   -> OPEN_ELEMENT with lpstrElementName=foo.ext
   open sequencer!foo.ext        same with lpstrElementName=foo.ext

 2 open new type xyz  -> OPEN_ELEMENT with empty ("") lpstrElementName

 3 open waveaudio     -> OPEN_ELEMENT unset, and
   capability sequencer (auto-open) likewise

E.g. native behaviour:
stop sequencer => \
stop waveaudio => MCIERR_UNSUPPORTED_FUNCTION
Current dlls/mciwave doesn't recognize that (no distinction between opening for recording and the
capability query mode), and it cannot do it for as long as this bug in winmm remains.

BTW, my mciseq rewrite w.r.t. threads is ready, see bug #22978 comment #9, however it's split across
over a dozen patches and I need to perform a lot of git rebase, reorder, squash and edit'ing.
So it'll not be ready for Friday.

Regard,
 Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-winmm-The-open-new-.-MCI-string-command-sets-an.patch
Type: application/octet-stream
Size: 1560 bytes
Desc: 0001-winmm-The-open-new-.-MCI-string-command-sets-an.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20120926/0498395e/attachment-0001.obj>