inconsistencies in MCI headers w.r.t. to 64bit
Dmitry, On 1/1/2004 you changed include/digitalv.h: DWORD dwReturn to DWORD_PTR However mmsystem.h uses DWORD. This is indeed what MSDN documents http://msdn.microsoft.com/en-us/library/dd798406%28VS.85%29.aspx http://msdn.microsoft.com/en-us/library/dd743409%28VS.85%29.aspx yet I refuse to believe it. I believe that all the MCI_XYZ_PARMS structures are consistent, so that a generic MCI string command parser is possible. That requires regular types. Eric Pouech wrote: http://www.winehq.org/pipermail/wine-devel/2010-February/081660.html
in that case, we (likely) need to write integral values as DWORD (on both 32 and 64 bit systems) and strings & pointers as DWORD_PTR
Indeed I believe that MCI_INTEGER (and hence dwReturn) should be mapped to DWORD and MCI_STRING (hence lpstrReturn) to DWORD_PTR. I believe EPP and part of AJ's recent winmm patches are wrong about 64bit. That could explain crashes or timeouts test.winehq shows for all machines running 64bit Wine (as opposed to 64bit Linux systems running 32bit Wine) in the mci tests. What evidence did you have for these changes? MSDN only or tests with natively compiled programs on native 64bit systems? Michael Stefaniuc wrote: http://www.winehq.org/pipermail/wine-devel/2010-February/081853.html
WTB uses Mingw to build the tests
I could write a patch, but how to test it? WTB has 64bit boxes, but I don't know what headers WTB uses for compilation (MingW or Wine ones?) and thus whether to trust binaries compiled on WTB. OTOH, it might be that MS is really so messy that incompatible structure definitions are used and that the MCI command string parser is full of special fixes for particular devices. This might not be the first time. I already spotted a case with AVIVIDEO where the resource and structure layout are not in the same order: Look up SETVIDEO Quality and Algorithm and see for yourself. This means that Wine's regular parser -- and perhaps native as well, who knows -- fill the structure in an order incompatible with MCI_DGV_SETVIDEO_PARMS. It is possible that native's parser knows about this and fixes the order. As I don't know how to test that function, I never publicly wrote about this before. In the end, - what headers does WTB's MingW use for compilation? - Does anyone have an other idea why the mci and midi tests hang or crash on systems running wine64? Regards, Jörg Höhle
Joerg-Cyril.Hoehle(a)t-systems.com a écrit :
Dmitry,
On 1/1/2004 you changed include/digitalv.h: DWORD dwReturn to DWORD_PTR However mmsystem.h uses DWORD.
This is indeed what MSDN documents http://msdn.microsoft.com/en-us/library/dd798406%28VS.85%29.aspx http://msdn.microsoft.com/en-us/library/dd743409%28VS.85%29.aspx
yet I refuse to believe it. I believe that all the MCI_XYZ_PARMS structures are consistent, so that a generic MCI string command parser is possible. That requires regular types.
Eric Pouech wrote: http://www.winehq.org/pipermail/wine-devel/2010-February/081660.html
in that case, we (likely) need to write integral values as DWORD (on both 32 and 64 bit systems) and strings & pointers as DWORD_PTR
Indeed I believe that MCI_INTEGER (and hence dwReturn) should be mapped to DWORD and MCI_STRING (hence lpstrReturn) to DWORD_PTR. I believe EPP and part of AJ's recent winmm patches are wrong about 64bit. That could explain crashes or timeouts test.winehq shows for all machines running 64bit Wine (as opposed to 64bit Linux systems running 32bit Wine) in the mci tests.
What evidence did you have for these changes? MSDN only or tests with natively compiled programs on native 64bit systems?
Michael Stefaniuc wrote: http://www.winehq.org/pipermail/wine-devel/2010-February/081853.html
WTB uses Mingw to build the tests
I could write a patch, but how to test it? WTB has 64bit boxes, but I don't know what headers WTB uses for compilation (MingW or Wine ones?) and thus whether to trust binaries compiled on WTB.
OTOH, it might be that MS is really so messy that incompatible structure definitions are used and that the MCI command string parser is full of special fixes for particular devices.
This might not be the first time. I already spotted a case with AVIVIDEO where the resource and structure layout are not in the same order: Look up SETVIDEO Quality and Algorithm and see for yourself. This means that Wine's regular parser -- and perhaps native as well, who knows -- fill the structure in an order incompatible with MCI_DGV_SETVIDEO_PARMS. It is possible that native's parser knows about this and fixes the order. As I don't know how to test that function, I never publicly wrote about this before.
In the end, - what headers does WTB's MingW use for compilation? - Does anyone have an other idea why the mci and midi tests hang or crash on systems running wine64?
as I already wrote, the changes I made to the mci parser are (partly) wrong, and should be rewritten to support MCI_INTEGER as DWORD and MCI_STRING (and friends) as DWORD_PTR (it currently maps everything to a DWORD_PTR) this bad stuff makes winetest segfaults on 64bit wine A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
<Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
On 1/1/2004 you changed include/digitalv.h: DWORD dwReturn to DWORD_PTR However mmsystem.h uses DWORD.
This is indeed what MSDN documents http://msdn.microsoft.com/en-us/library/dd798406%28VS.85%29.aspx http://msdn.microsoft.com/en-us/library/dd743409%28VS.85%29.aspx
yet I refuse to believe it. I believe that all the MCI_XYZ_PARMS structures are consistent, so that a generic MCI string command parser is possible. That requires regular types.
You should check the PSDK headers, not MSDN online. -- Dmitry.
Hi, you guys running Wine64 on 64bit UNIX, please test the patch attached to bug #22146 http://bugs.winehq.org/show_bug.cgi?id=22146 The patch is available from http://bugs.winehq.org/attachment.cgi?id=27027 Test code that you can use for reporting is at: http://bugs.winehq.org/attachment.cgi?id=27028 I'm afraid my patch does not apply cleanly in Wine-1.1.41. You'll likely need to skip, remove or correct the one hunk about TRACE(...data[]...). It's not essential. Actually, I've removed %s formatting from the 64bit trace because I don't know how Wine behaves when given a bad pointer -- TRACE("%s",debugstr(random_location)) could even cause a core dump, couldn't it? Thank you very much, Jörg Höhle
Joerg-Cyril.Hoehle(a)t-systems.com schrieb:
Hi,
you guys running Wine64 on 64bit UNIX, please test the patch attached to bug #22146 http://bugs.winehq.org/show_bug.cgi?id=22146
The patch is available from http://bugs.winehq.org/attachment.cgi?id=27027
Test code that you can use for reporting is at: http://bugs.winehq.org/attachment.cgi?id=27028
I'm afraid my patch does not apply cleanly in Wine-1.1.41. You'll likely need to skip, remove or correct the one hunk about TRACE(...data[]...). It's not essential. Actually, I've removed %s formatting from the 64bit trace because I don't know how Wine behaves when given a bad pointer -- TRACE("%s",debugstr(random_location)) could even cause a core dump, couldn't it?
Thank you very much, Jörg Höhle
It seems you missed something in your patch, i get: gcc -c -I../../../../dlls/winmm/tests -I. -I../../../../include -I../../../include -DWINE_STRICT_PROTOTYPES -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -o mci.o ../../../../dlls/winmm/tests/mci.c ../../../../dlls/winmm/tests/mci.c: In function ‘test_mciParser’: ../../../../dlls/winmm/tests/mci.c:183: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘long unsigned int’ ../../../../dlls/winmm/tests/mci.c:184: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘long unsigned int’ ../../../../dlls/winmm/tests/mci.c:187: warning: statement with no effect ../../../../dlls/winmm/tests/mci.c:193: warning: statement with no effect ../../../../dlls/winmm/tests/mci.c:202: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:203: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:206: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:206: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:208: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:209: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:212: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:212: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:214: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:215: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:218: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ ../../../../dlls/winmm/tests/mci.c:218: error: ‘MCI_PARMS_UNION’ has no member named ‘caps’ make: *** [mci.o] Fehler 1 -- Best Regards, André Hentschel
participants (4)
-
André Hentschel -
Dmitry Timoshkov -
Eric Pouech -
Joerg-Cyril.Hoehle＠t-systems.com