Wine 64 bit

[cdavis5x at gmail.com]

> On Jan 8, 2015, at 10:11 PM, Ken Thomases <ken at codeweavers.com> wrote:
> 
> Hi,
> 
> I am attaching a new patch to get Wine building and running 64-bit on OS X.  This now launches built-in programs like winecfg, etc.  I have also run the MSI installers for SketchUp and 7-Zip; although they seemed to go through to completion, they didn't work completely correctly.  (I'm not sure prefix creation was right, either.)
> 
> This is based on strooka's work at <https://github.com/strook/wine-dev-x86_64/commit/5dd3cca2200cdf1b6fa5afb185e5086500df4130>.  (I started this before his subsequent commit and my work largely eliminates the need for that one.)
> 
> I have rebased onto current git tip (wine-1.7.33-191-ge899bd8).  strooka's work was based on 1.7.8.
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.

Apple GCC won’t work for obvious reasons, so you need either vanilla GCC or Clang. I haven’t tested with FSF GCC, but if you use Clang, you need to build it yourself with some patches against LLVM and Clang that I wrote (and that I have also attached), but haven’t yet bothered upstreaming. Some of them fix nasty miscompiles when mixing System V and Win64 calling conventions, and others, of course, add support for __ms_va_list. They are, of course, against LLVM tip-of-tree.

Mine doesn’t seem to work correctly, either; there are some other issues that may or may not be related to Clang/LLVM miscompiles that I haven’t fixed yet. In particular, there were some pretty hairy issues with DWARF debug information that made symbolic debugging nigh impossible.

> 
> This is still a hack-and-slash job, although I have cleaned up some of strooka's work.  In particular, the changes to dlls/ntdll/signal_x86_64.c are much simpler and cleaner.
> 
> Since it's a hack job, it will break builds for other platforms/architectures, including 32-bit Wine for OS X.  As a consequence, you would have to maintain separate source bases to build a shared WoW64 setup.  I haven't tried yet.
My patches do not have this problem ;). I had my eye on WoW64 from the start.
> 
> The configure line that strooka recommended had a lot of extraneous stuff.  I configured with:
> 
> ./configure --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib --enable-win64 --disable-wineqtdecoder --disable-win16
I thought --disable-win16 was implicit in --enable-win64. Also, one of my patches automatically disables wineqtdecoder if Wine64 is enabled.
> 
> The Mac driver crashes in a 64-bit build for reasons I haven't investigated, so you have to use the X11 driver.
Yipe! I think I recall having this problem myself.

Chip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wine64-macos.tar.bz2
Type: application/x-bzip2
Size: 10552 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150109/56c456ab/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-win64.tar.bz2
Type: application/x-bzip2
Size: 13296 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150109/56c456ab/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-win64.tar.bz2
Type: application/x-bzip2
Size: 10893 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150109/56c456ab/attachment-0005.bin>