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

Eric Pouech eric.pouech at orange.fr
Fri Mar 19 15:30:23 CDT 2010


Joerg-Cyril.Hoehle at 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)






More information about the wine-devel mailing list