Wine 64 bit

[Ken Thomases]

On Jan 23, 2015, at 12:03 AM, cdavis5x at gmail.com wrote:

> On Jan 22, 2015, at 8:58 PM, Ken Thomases <ken at codeweavers.com> wrote:
>> 
>>> 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.

Yeah, I realized after I sent that that NtCurrentTeb() must not be exported on Windows for 64-bit.  So, your approach is probably right.  It shouldn't be exported in Wine, either.

>> 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.

I don't know if Alexandre will allow that.  He wasn't willing to drop support for 10.5 back when the Mac driver was added.  He was even kind of grumpy that the Mac driver itself required 10.6.  At the time, he had an old Mac Mini that couldn't be upgraded past 10.5 that he continued to build and test on.

Perhaps if dropping 10.5 gained us something, he could be persuaded.  I just figured that support for an additional architecture could be restricted, since it doesn't remove something that used to work.  On the other hand, if the only concession we need to make is this set of macros being defined two different ways, that's not much of a cost.


>>> 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.

Yeah, I didn't really mean to say that was a problem with this patch.  Just musing about what ultimately needs to be done.

> But the nlist(3) call isn’t available on 64-bit, nor is the n_un.n_name field in struct nlist{,_64}

Huh.  I realized the n_name field was missing, but didn't realize that nlist() isn't available.  The function declaration isn't excluded for __LP64__ in the header, but, you're right, it's not exported by libSystem or its sub-libraries.

> ——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.

> Thanks for the review!

You're welcome. :)

-Ken