New subject: 64bit bit Wine users, please test patch

19 Mar 2010


      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

inconsistencies in MCI headers w.r.t. to 64bit