Wine 64 bit

Stefan Dösinger stefandoesinger at gmail.com
Fri Feb 21 05:09:23 CST 2014


Am 20.02.2014 um 22:51 schrieb Ken Thomases <ken at codeweavers.com>:
> This will actually be more complicated than stack alignment (__force_align_arg_pointer__) and the hook prologue.  With stack alignment, Windows code is not allergic to 16-byte-aligned stack, it just fails to maintain it.  So, it's sufficient for us to force 16-byte alignment when Windows code calls into Wine code.  When Wine code calls out to Windows code, there's nothing we need to do.  So, putting the attribute in the WINAPI declspec works.
Good point.

> 1) Wrap all calls out to system libraries.  Save the register, restore what the OS X ABI expects/requires, call the system API, restore the original value of the register.
We’d also have to take care of places where the system API calls us. I guess the problem is essentially the same as in option 2. I think 2 is the better approach. With 1 there may be cases where the compiler generates code from the Wine sources that expects the OSX register setup.

> 2) Conceptually wrap the Windows code.  This has a component similar to stack alignment and the hook prologue, but also has to affect all places that call out to Windows code.  Where Windows code calls Wine code, we'd save the Windows value of the register and restore the OS X ABI value.  When the Wine code returns, it would restore the Windows value.  But also, wherever Wine calls out to Windows code, it will have to save the OS X ABI value, restore the Windows value, do the call-out, then restore the OS X ABI value.
There are more problems: I doubt that we can store the register values on the stack. It would probably need some thread local storage, which would be a Wine-specific location. (Isn’t the entire issue about the TLS pointer?). Putting this Wine-specific knowledge into the compiler would be very ugly. Even formulating a reasonable interface for such a compiler feature will be a challenge.

A better option than the WINAPI / CDECL attribute might be exported symbols, quite like +relay works. But then we need a solution for COM methods.

Also, what happens if Wine code calls a public Windows function? The register store / restore function should be save to apply in this case.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140221/f7250c1c/attachment.sig>


More information about the wine-devel mailing list