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