[PATCH 1/3] winmm: Functions that take an open HWAVE don't need StartDevicesThread.

Joerg-Cyril.Hoehle at t-systems.com Joerg-Cyril.Hoehle at t-systems.com
Wed Aug 3 07:38:17 CDT 2011


This is the same as last week, resent for ease of use.

I don't think there should be a rule "every top-level wave*
function should call StartDevicesThread first".

Functions that receive an open HWAVEIN/OUT handle will have had
StartDevices called at Open time.
If not, WINMM_GetDeviceFromHWAVE will return INVALHANDLE
after seeing a zero g_*_count.

Functions like wave*Open and getNumDevs need StartDevicesThread.

There's still another bug in the new winmm:
Like midiOutGetVolume, waveOutGet/SetVolume
must accept a device identifier (a small int) beside a handle
to an open HWAVEIN/OUT object.  The current code does not know
about that dual use.
The old winmm code knew MMDRV_Get(... BOOL bCanBeID).

Likewise, GetDevCaps must support this dual interface.
I once added corresponding tests to the MIDI testsuite.  Unfortunately,
there's nothing similar in the wave* testsuites.
IMHO, the testsuite did a fair job w.r.t. the old state of Wine, but was
not designed to test a complete rewrite.

I've not applied the same change to the mixer as I've almost never
looked at the mixer API or code. I vaguely remember that MSDN says
one can supply small ints (identifiers) beside handles too.

This patch follows the previous one in my git tree, but is independent.

 Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-winmm-Functions-that-take-an-open-HWAVE-don-t-need.patch
Type: application/octet-stream
Size: 6106 bytes
Desc: 0004-winmm-Functions-that-take-an-open-HWAVE-don-t-need.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20110803/e6a73f2f/attachment-0001.obj>

More information about the wine-patches mailing list