Re: Understanding 64bit implications and wine64
On Mon, Feb 08, 2010 at 11:27:07AM +0100, joerg-cyril.hoe...@t-systems.com wrote: 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? A 32bit (i386) windows application binary can only run in a 32bit Unix application [1]. In which case the Unix kernel will handle the system call emulation and ensure that the only user-space virtual addresses the application sees are 32bit (it may be able to give the app almost 4G of user address space - instead of the usual 3G). Wine may allow both 32bit and 64bit clients to talk to its server process - and that may need care so that only fixed-size types are used. David [1] The instruction sets are different - the single byte opcodes for inc/dec register are reallocated for other uses. So you cannot just load 32bit code into a 64bit binary and expect anything sane to happen. -- David Laight: da...@l8s.co.uk
Re: Understanding 64bit implications and wine64
On 9 February 2010 18:16, David Laight da...@l8s.co.uk wrote: A 32bit (i386) windows application binary can only run in a 32bit Unix application [1]. In which case the Unix kernel will handle the system call emulation and ensure that the only user-space virtual addresses the application sees are 32bit (it may be able to give the app almost 4G of user address space - instead of the usual 3G). So the Wine on my 64-bit Ubuntu (which works perfectly well) is actually a 32-bit app? I didn't know that! - d.
Re: Understanding 64bit implications and wine64
On 10 February 2010 09:11, David Gerard dger...@gmail.com wrote: On 9 February 2010 18:16, David Laight da...@l8s.co.uk wrote: A 32bit (i386) windows application binary can only run in a 32bit Unix application [1]. In which case the Unix kernel will handle the system call emulation and ensure that the only user-space virtual addresses the application sees are 32bit (it may be able to give the app almost 4G of user address space - instead of the usual 3G). So the Wine on my 64-bit Ubuntu (which works perfectly well) is actually a 32-bit app? I didn't know that! Yup. If Wine runs win32 apps (which most Windows apps are), then it's 32bit. WoW64 for the win64+win32 wine is not ready, afaik.
Understanding 64bit implications and wine64
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
Re: Understanding 64bit implications and wine64
joerg-cyril.hoe...@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
Re: Understanding 64bit implications and wine64
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. actually, this patch is still broken I originally assumed that the MCI structs were 8-byte aligned on WIN64, which is wrong actually, it's 4 byte aligned, meaning that we need some more work on MCI string parser to take care of this 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? 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 A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Understanding 64bit implications and wine64
All about 64-bit programming: http://www.viva64.com/articles/64-bit-development/ Articles , http://www.viva64.com/links/64-bit-development/ Articles Reviews , http://www.viva64.com/blog/en/tag/64-bits/ Blog . -- View this message in context: http://old.nabble.com/Understanding-64bit-implications-and-wine64-tp27497865p27510882.html Sent from the Wine - Devel mailing list archive at Nabble.com.
Re: Understanding 64bit implications and wine64
Andrey_Karpov kar...@viva64.com wrote: All about 64-bit programming: http://www.viva64.com/articles/64-bit-development/ Articles , http://www.viva64.com/links/64-bit-development/ Articles Reviews , http://www.viva64.com/blog/en/tag/64-bits/ Blog . To be honest it would be better to start with http://wiki.winehq.org/Wine64 and referring first to Microsoft's Programming Guide for 64-bit Windows http://msdn.microsoft.com/en-us/library/bb427430%28VS.85%29.aspx instead of plugging your own guides (regardless how useful they are). -- Dmitry.
