Wine 64 bit

[Kevin Davies]

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 at gmail.com
> wrote:

>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140222/217ec593/attachment-0001.html>