Hi,
I've trouble understanding some of the 64bit issues. Lacking a 64bit machine, I'm left asking questions ;-)
My understanding is that wine64 is the effort to make Wine work on 64bit UNIX systems, i.e. pointer size = 64bit, isn't it? DWORD_PTR is 64 bit wide on a wine64 system, 32 bit otherwise, correct?
A priori, this has nothing to do with MS-Windows' LARGE_ADDRESS_SPACE_AWARE(sp?) API, which I believe allows 32bit apps to nevertheless make use of more than 1,5/2/4GBof RAM, isn't it?
The wine64 challenge seems to let 32bit MS-windows apps work even though the UNIX side has to manage pointer addresses >2^32, i.e. above the lower 4GB address range. Is there some address translation involved or only mmap'ing? What must the Wine developer know to write correct code for wine64?
For instance, I fail to understand Erich Pouech's recent commit 5cab72bc95ec2d864e19952fff2df99610ba7537 winmm: For MCI parsing, use 64bit compatible variables.
If you look closely at the definitions of MCI_xyz_PARMS in MMSYSTEM.H, you'll notice that (at least on 32bit systems), despite the different types (DWORD, LPSTR, UINT) these structures are originally an array of 32bit values. This regular structure is essential, because the MCI command parser has very limited means to know about different sizes. All it knows is MCI_INTEGER, MCI_STRING, MCI_CONSTANT.
An app that sends an MCI_xyz command sends a pointer to such an array, decorated as MCI_xyz_PARMSA/W for nicer access. Alternatively, when using mciSendString, the MCI parser builds this array of DWORD elements, then calls the MCI command. In recent Wine, this has become an array of DWORD_PTR instead. wine-tests may work because Wine is cnosistent with itself, but How can this possibly work without breaking binary compatibility?
Thanks for your help, Jörg Höhle