Wine 64 bit

[cdavis5x at gmail.com]

> On Jan 22, 2015, at 8:58 PM, Ken Thomases <ken at codeweavers.com> wrote:
> 
> 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?
Oh this? A while ago, I noticed that when building everywhere else, libwine restricts its exports (cf. wine.def and wine.map). I guess this is necessary for Windows (because we don’t mark the APIs with __declspec(dllexport)), but we do this on ELF platforms, too. And so I thought to myself, why aren’t we doing this on Mac, too?

This happened to be in my tree when I wrote the other patches. #3 depends on it right now, and I didn’t feel like rewriting it not to need it at the time I packaged up these patches for you guys. If Alexandre won’t take it, I guess I can remove this patch.
> 
>> 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.
I imagine he would, given that a) Apple is likely to remove the QuickTime headers at some point, and b) testing for availability is good autoconf practice anyway. I’ll fix that.
> 
>> 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.
It’s conditional in my tree because I have another patch that turns off the __PAGEZERO segment, then sticks the WINE_DOS segment at address 0. I submitted that patch once, but Alexandre rejected it because we lack V86 support anyway on Mac OS, so what’s it matter if Win16 and Win9x programs can’t access the IVT, BDA or DOS Data Segment? :) I guess I could make it unconditional (since he’s not going to take my patch to make it 0 on 32-bit), but it’d be redundant on 32-bit, because the default size of the __PAGEZERO segment there is 4k.
>  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.
I must have glossed over that when I was reading the ld(1) man page. I’ll definitely fix that——even if, in the grand scheme of things, it won’t make that much more memory available.
> 
>> 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. ;)
I'll submit this right away.
> 
>> 0005-server-Use-mach_vm_-functions-instead-of-the-old-vm_.patch
> 
> Seems good.
This too.
> 
>> 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?
Yep. I didn’t want to add an export of an NT API that is not exported on Windows. I’m just afraid that some program out there depends specifically on NtCurrentTeb() not being in ntdll’s export table on x64. Yes, I know it sounds paranoid, but you just never know what programs in the wild (at least, the proprietary ones) depend on.
>  Is it possible to define NtCurrentTeb() such that it's inlined but also exported by ntdll on the other platforms?
Given that that’s what we already do for some other API functions, probably. (GetLastError() in kernel32 comes to mind.)
>  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.
Should we then refuse to build Wine at all on Darwin 9 (= OS X 10.5)? There’s some more conditional checks we can then get rid of if we require Mac OS 10.6.
> 
> You seem to have some cruft.  Is the #include <sys/sysctl.h> used?
Nope, and I meant to get rid of that. It was used in an earlier version of my patch to set kern.thaltstack, but when I removed that (because it’s a no-op in Mac OS >= 10.5), I forgot to remove the #include.
>  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. ;)
Hey, it’s no problem. I appreciate 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.
I know. But the nlist(3) call isn’t available on 64-bit, nor is the n_un.n_name field in struct nlist{,_64}——even when inspecting a 32-bit binary. (I wonder if Alexandre would prefer configure checks for those…) So it wouldn’t build at all as is, and while I was in there I figured I’d fix it more or less the right way.
>  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.
I should check on that. I never did actually try to use a 64-bit WinDbg/CDB/NTSD on a 32-bit binary, so I’m curious to know if that would work.
> 
>> 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.
I’ll submit all of these.
> 
> Thanks!  I'll be interested to see where this leads.
Thanks for the review!

Chip

> 
> -Ken
>