Understanding 64bit implications and wine64

[Joerg-Cyril.Hoehle at t-systems.com]

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