http://bugs.winehq.org/show_bug.cgi?id=13892
Summary: mmioOpen MMIO_ALLOCBUF not ignored when passed a buffer Product: Wine Version: 1.0-rc4 Platform: Other URL: http://www.bzuniverse.com/forum/index.php/topic,7907.0.h tml OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci AssignedTo: wine-bugs@winehq.org ReportedBy: work.eric@gmail.com
Sounds previously did not work in Battlezone II, but was fixed by the developer with the latest beta. Here are his comments about the fix.
"And as to the audio issues, this is WINE not being bug-for-bug compatible with Windows. http://msdn.microsoft.com/en-us/library/ms712181(VS.85).aspx describes the function that I changed this week. It seems that Windows safely ignores MMIO_ALLOCBUF when passed a memory buffer. WINE blew chunks. You can consider this a bug report that should be filed with the WINE devs."
http://bugs.winehq.org/show_bug.cgi?id=13892
Eric Work work.eric@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|other |Linux Platform|Other |PC-x86-64
http://bugs.winehq.org/show_bug.cgi?id=13892
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2008-06-14 04:04:01 --- Created an attachment (id=13991) --> (http://bugs.winehq.org/attachment.cgi?id=13991) Make the tests for MMIO_ALLOCBUF pass in Wine
Does the attached patch help?
http://bugs.winehq.org/show_bug.cgi?id=13892
--- Comment #2 from Eric Work work.eric@gmail.com 2008-06-14 11:48:43 --- The attached patch did not fix the problem. I actually noticed the same bug myself while trying to figure out the problem. I believe this is what the program is trying to do.
"To open a memory file using an application-supplied buffer, set pchBuffer to point to the memory buffer, fccIOProc to FOURCC_MEM, cchBuffer to the size of the buffer, and adwInfo to the incremental expansion size of the buffer. The expansion size in adwInfo should be nonzero only if pchBuffer is a pointer obtained by calling the GlobalAlloc and GlobalLock functions; in this case, the GlobalReAlloc function will be called to expand the buffer. In other words, if pchBuffer points to a local or global array or a block of memory in the local heap, adwInfo must be zero. Specify the MMIO_CREATE flag for the dwOpenFlags parameter to initially set the end of the file to be the beginning of the buffer. Otherwise, the entire block of memory is considered readable."
Since MMIO_ALLOCBUF was set, it reallocates the buffer losing the original buffer with the RIFF data. At least that's what I think is happening.
Running both versions with WINEDEBUG=-all,+mmio; the first line differs.
1.3pb3: trace:mmio:MMIO_Open ('(null)', 0x6e23a8, 00010000, 1); 1.3pb4: trace:mmio:MMIO_Open ('(null)', 0x64f038, 00000000, 1);
The MMIO_ALLOCBUF flag is no longer set, which is how the developer fixed the problem.
Things are mostly the same until these lines.
1.3pb3: trace:mmio:mmioSeek (0x1, 00000000, 1); 1.3pb3: trace:mmio:mmioDescend dwOldPos=-1
1.3pb4: trace:mmio:mmioSeek (0x1, 00000000, 1); 1.3pb4: trace:mmio:mmioSeek => 0 1.3pb4: trace:mmio:mmioDescend dwOldPos=0
http://bugs.winehq.org/show_bug.cgi?id=13892
--- Comment #3 from Eric Work work.eric@gmail.com 2008-06-14 13:19:52 --- Created an attachment (id=14020) --> (http://bugs.winehq.org/attachment.cgi?id=14020) Additional Fixes for MMIO_Open
This patch includes the fixes from the previous patch.
It turns out that MMIO_SetBuffer (called from MMIO_Open) does free the internal buffer because of the MMIO_ALLOCBUF flag, but the internal buffer is already NULL so it has no effect and the flag is cleared anyways after this is done. The application supplied buffer was indeed being used and not deallocated (like I thought). Without the previous patch running wine with trace+mmio would cause a GPF due to the buffer size being set incorrectly (relative to the application supplied buffer) to MMIO_DEFAULTBUFFER every time and this caused problems with mmioDescend it seems. The problem in the end was that wm->bBufferLoaded was not being set to TRUE for the MMIO_ALLOCBUF case causing MMIO_SEEK to fail and then mmioDescend never finds the RIFF data.
http://bugs.winehq.org/show_bug.cgi?id=13892
Eric Work work.eric@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=13892
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=13892
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2008-06-18 22:09:36 --- Could you please retest with today's git? A modified version of the patch has been committed.
http://bugs.winehq.org/show_bug.cgi?id=13892
Eric Work work.eric@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #5 from Eric Work work.eric@gmail.com 2008-06-20 02:42:07 --- Patch confirmed! Git version of winmm.dll.so works with Battlezone II 1.3pb3 and 1.3pb4 where it previously only worked with 1.3pb3. Good work guys! Battlezone II, as far as I can tell, works perfectly. Closing this bug as fixed.
http://bugs.winehq.org/show_bug.cgi?id=13892
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2008-06-27 10:36:28 --- Closing bugs fixed in 1.1.0.
-
wine-bugs＠winehq.org