mciqtz32: Fix open/close omissions (resend)

Joerg-Cyril.Hoehle at t-systems.com Joerg-Cyril.Hoehle at t-systems.com
Mon Nov 30 09:05:56 CST 2009


Hi,

>You need to provide more information why is this change
>required, and what is the problem you are trying to fix.

I came across the following when comparing the various mci* implementations since
my work on mciwave is just a warm-up (still on-going).  MCICDA and MIDI is where
more apps hang AFAICT, and now I also found issues with MCIAVI.
Ideally, patches to fix A in mciX should be followed by N similar pacthes to
fix mciY/mciZ.dll.  The implementations should look similar, that would make
reviewers (like me) feel comfortable.  But we are far from that.
I'm working on it, though ;-)

@@ -105,6 +105,7 @@ static DWORD MCIQTZ_drvClose(DWORD dwDevID)
+        mciSetDriverData(dwDevID, 0);

See MCI_UnloadDriver:
    if (wmd->dwPrivate != 0)
        WARN("Unloading mci driver with non nul dwPrivate field\n");
It is drvClose's contract to mark dwPrivate as released (0).


-    if (!((dwFlags & MCI_OPEN_ELEMENT) && (dwFlags & MCI_OPEN_ELEMENT))) {
That repetition is obviously bogus. Thinking about what the OP might have
had in mind, I came to the conclusion that
+    if (!(dwFlags & MCI_OPEN_ELEMENT) || (dwFlags & MCI_OPEN_ELEMENT_ID)) {
is the appropriate test.  When ELEMENT_ID is set, there's no ELEMENT name
(rather a re-use of string buffer as a DWORD place), so the code that follows
must be protected against that sort of input.

Regards,
	Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mciqtz32-Harmonize-behaviour-among-MCI-devices.patch
Type: application/octet-stream
Size: 1089 bytes
Desc: 0001-mciqtz32-Harmonize-behaviour-among-MCI-devices.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20091130/edba2b8d/attachment.obj>


More information about the wine-patches mailing list