Understanding 64bit implications and wine64

[Michael Stefaniuc]

Joerg-Cyril.Hoehle at t-systems.com wrote:
> 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
Not at all. Wine64 is to let Win64 bit apps on Wine too; of course Wine
running on a 64bit host. Win32 apps will work on Wine64 too through WoW64.

> 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,
And pointers on 64bit Windows are 64bit. Thus the variable that holds
that pointer needs to be 64bit too on Wine64. That's achieved by
changing from DWORD to DWORD_PTR.

> 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?
DWORD_PTR has the size of a void pointer which is 32bit on 32bit Wine.
Aka DWORD and DWORD_PTR have the same size on Wine32 and thus binary
compatibility is still there.


bye
	michael