Stefan its surprising how both Windows and OSX run on the same Intel platform but in very different ways. However when you consider the pedigree of these systems it's not so surprising. They come from very different worlds.

Thank you gentlemen. It's pretty clear then it's not available now, nor will it be without some significant effort. I understand the conversation thus far if not some of the finer details. You have answered my question.

 


On Fri, Feb 21, 2014 at 10:09 PM, Stefan Dösinger <stefandoesinger@gmail.com> wrote:

Am 20.02.2014 um 22:51 schrieb Ken Thomases <ken@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.