Wine 64 bit

[Charles Davis]

Sorry for the belated response. GCC takes forever to build on my system.

> On Apr 28, 2015, at 8:26 AM, Josh DuBois <duboisj at codeweavers.com> wrote:
> 
> 
> I was interested in compiling 64-bit wine on OS X the other day and hit some problems, so I thought I would resurrect this thread.  I used gcc 4.8 from macports, because as far as I could tell there wasn't a chance of using any version of clang without patching it. Using gcc I hit winehq bug 38380 right away:
> 
> https://bugs.winehq.org/show_bug.cgi?id=38380
> 
> With Ken's help I tried the attached patch, which allowed a few places where wine has assembly code calling 64-bit windows functions to assemble with Apple's broken assembler.
I don’t use Apple’s broken as(1), because I patch Clang, whose integrated assembler is decidedly un-broken. That’s why I never submitted a patch for that. (In fact, it’s possible to make as(1) invoke Clang to do the assembly, if you pass it the ‘-q’ switch.)

I still need to get my __ms_va_list patches upstream into LLVM/Clang, but there’s a big rewrite going on related to pointer types in LLVM IR that affects my patch (i.e. it’ll make it simpler), so I’m waiting for that to go through first.
> 
> The only other problem I hit was the pagezero thing discussed below:
> 
> On 1/23/15 12:03 AM, cdavis5x at gmail.com wrote:
>>>> 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.
> Did any resolution to this problem ever appear?
Just now, attached to this email. ;) (NOTE: You’ll have to regenerate configure after applying this change.)
>  If that were fixed and we had a workaround for the broken Apple assembler, I think you could compile and test 64-bit wine on OS X.  (The mac driver still won't compile without clang, but passing --disable-winemac.drv at least allowed use of the X11 driver.)
> 
> I haven't tested much so far, but I at least got a working prefix and ran notepad (once with relay logging, even).
That’s great! In fact, that’s actually further than I get building with Clang—even with my patches applied to it. (It doesn’t help that Clang produces broken DWARF unwind info for Win64 ABI functions, which I really need to fix…)

By the way, I can tell you right now that WoW64 won’t work quite yet. Mac OS has no separate lib32/lib64 directories, so we need to produce fat DLLs. I have another patch (also attached) to teach kernel32 to recognize fat binaries, but there’s no build system infrastructure for making fat DLLs yet. If you want to try out WoW64, you’ll have to do that manually with lipo(1). (I’ve actually submitted this second patch, but AJ hasn’t taken it. I guess he’s unconvinced that it’s correct. Maybe if we try out WoW64 and it works, he’ll be more convinced. ;)

Chip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-configure-Support-64-bit-compilation-on-Mac-OS.patch
Type: application/octet-stream
Size: 2661 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150428/10edf8d2/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-kernel32-Also-recognize-and-handle-Mach-O-fat-binari.patch
Type: application/octet-stream
Size: 4499 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150428/10edf8d2/attachment-0003.obj>