Wine 64 bit

Ken Thomases ken at codeweavers.com
Thu Jan 22 21:58:20 CST 2015


On Jan 9, 2015, at 3:56 AM, cdavis5x at gmail.com wrote:

> Funny you should mention that, since I have my own patches for Wine64 on Mac OS, which I’m now attaching to this email. It’s a bit less hacky than strooka’s (even if I do say so myself), in part because the __ms_va_list stuff isn’t defined away. I have rebased my patches onto Wine HEAD as of tonight.

Should have replied earlier, but… this is good stuff.  A number of these patches should just be submitted now.  They would be good to have even if they don't eventually get us to working 64-bit Wine on OS X:

> 0001-libwine-Add-exports-file-for-Mac-OS.patch

Not sure what this is about.  I assume this is about restricting what symbols are exported.  Is there a problem with excessive exports?

> 0002-configure-Don-t-build-a-64-bit-wineqtdecoder.patch

I don't have a problem with this as is, but Alexandre may prefer an actual test of QuickTime's availability.

> 0003-configure-Support-64-bit-compilation-on-Mac-OS.patch

Regarding the -pagezero_size option: 1) it might as well be unconditional.  The 32-bit code assumes a 4096-byte page-zero, implicit in the base address of WINE_DOS.  2) I assume it works to specify it in decimal or you'd still be getting linker errors.  However, the ld man page says it is interpreted as hexadecimal with or without a leading "0x".  So, probably better to specify it in hex.

> 0004-winebuild-Make-emitting-mod_-_func-sections-on-Mac-O.patch

This is clearly just better than the current code, which effectively has magic numbers.  I hadn't even bothered looking closely enough at this code to learn of the existence of get_ptr_size() and get_asm_ptr_keyword().  Sure makes my hack seem… extra hack-ish. ;)

> 0005-server-Use-mach_vm_-functions-instead-of-the-old-vm_.patch

Seems good.

> 0006-ntdll-Support-64-bit-Mac-OS.patch

Is the addition of the __wine_current_teb() your attempt to get around the fact that NtCurrentTeb() is inlined on other 64-bit platforms but has to be exported on OS X?  Is it possible to define NtCurrentTeb() such that it's inlined but also exported by ntdll on the other platforms?  This solution seems excessively convoluted.

I'm not sure we care about 10.5 with the 64-bit support.  That avoids the conditional definitions of the context accessor macros.

You seem to have some cruft.  Is the #include <sys/sysctl.h> used?  Certainly there's an empty #ifdef __APPLE__/#endif pair.  (I realize you're not done and I'm not one to talk given the hackfest I horked up.  Just trying to help. ;)

> 0007-dbghelp-Support-64-bit-dyld_all_image_infos-structur.patch

There's going to be a lot more that needs to be done for the dbghelp support.  It currently uses 32-bit-specific Mach-O structures and constants (e.g. MH_MAGIC, CPU_TYPE_X86, LC_SEGMENT, and struct segment_command).  I haven't checked if a 32-bit dbghelp will be expected to analyze a 64-bit process or vice versa.

> 0008-kernel32-Don-t-use-gs-on-64-bit-Mac-OS.patch
> 0009-kernel32-Recognize-64-bit-Mach-O-modules-too.patch
> 0010-kernel32-Also-recognize-and-handle-Mach-O-fat-binari.patch
> 0011-msvcrt-Support-64-bit-platforms-that-don-t-have-fini.patch

These all look fine.

Thanks!  I'll be interested to see where this leads.

-Ken




More information about the wine-devel mailing list