Apple

From Wine-Wiki

Jump to: navigation, search

Contents

Introduction

J. White [Mar06]: While being obscure during the days of PowerPC-only OS X, the question now of "What about Wine on OS X?" has become quite frequent in the Intel-era and will become more so. [...] a download of Wine for Intel OS X is probably still a month or two away[...] when CodeWeavers makes their CrossOver Office release. [...]

Shortly afterward he announced on the first of september: We just shipped a public beta of CrossOver for the Mac.


[..]For those who may not be clear, Darwine is not a fork of Wine, but a Wine developer forum focused on OS X (and Darwin) specific issues. wine archive

Ed. [Jul 06]Since Apple started using x86 machines, Wine has targetted these as well. Patches have been accepted for these. Those with Power PC systems can still look toward the clever efforts of the Darwin developers.

Segin[Mar 06]: 'Wine'[...] doesn't emulate a CPU. Therefore you cannot run x86 Windows programs on a PowerPC Macintosh.)

A user asked on the wine devel list: Are there any [...] intel/darwin areas that require attention or are being worked on?

A. Julliard: At this point, many simple apps should probably work OK. The main problems areas that need work are exception handling (mainly because of kernel bugs) and the debugger support that essentially doesn't work at all. You'll also need to disable optimizations when building because of the gcc stack-realign bug (we need to come up with a configure check for it), and you most likely have to use an x.org X server because the Apple one has some serious bugs in rootless mode. So it's not quite ready for prime time yet. We are hoping to have binary packages on WineHQ in the near future, that should make it somewhat easier to get things going.

W. Knop summarised: Overall Status: Simple applications should work. Notes:

  • Make sure to disable gcc optimizations when building since gcc has a stack realignment bug.
  • Also, Apple's X11 has serious bugs in rootless mode, so x.org's X11 may be necessary.

Tasks:

  • Quartz Driver: work in progress
  • Core Audio Driver: works
  • 16 Byte Stack Alignment: work in progress
  • Mach Kernel Workarounds and Exception Handling: needs a lot of work
  • Debugger: does not work

OS X

Ed Aug 08: Wine works on Mac x86 processors. But it needs a little bit of work to get it going.

wine user Aug 08Vitamin: Mac's OpenGL (or more precisely X server) doesn't work with Wine. You need Xorg's version of X.

Another users posted: This is very true if you have the stock Leopard's X11 installed. You need to get the version produced by the XQuartz for MacForge version. Their home page is at http://xquartz.macosforge.org Get the latest/greatest version and install it AFTER installing orverifying that X11 is installed on your Mac.


Mac Quartz

Work is on going to get wine using the Mac Quartz interface, but this is tricky work.

S. Edwards Mar 08 wine devel: There is a public branch where the Wine quartzdrv will go even if its not accepted in to Winehq. I have been from time to time bringing in infrastructure changes from the old winequartzdrv however the current tree is empty as the developer of the prior editions, Emmanuel Maillard, is in the process of overhauling it from recent changes to the Wine driver model. Keep an eye on

http://wiki.winehq.org/MacOSX/QuartzDriver

And hopefully in the next few weeks we will have a newer patch in the winequartzdrv tree for a more recent version of Wine. I am not sure what design changes Emmanuel is wanting to make but hopefully they will be more to Alexandre's liking and can eventually go in to normal winehq. If you want to work on quartzdrv with Emmanuel, send him an email to get an idea of what he needs and what the design will be, then apply for write access to http://repo.or.cz and I will add you to the winequartzdrv branch.

There is a script posted here to make it less of a hassle to build a stock Winehq release on OS X.

http://www.wine-forum.org/showthread.php?t=16

I'm happy to start making builds of Winehq snapshots for OS X. I just don't see the point when the Darwine packages are better for the end user experience. With Winehelper you get Doc integration and a partial menu system. The stock X.org on OS X is broken and has inherit overhead that will always be present, being able to write directly to the native Windowing system seems like a much more logical long term solution rather than trying to keep Xorg from breaking and or developing hacks to work around X and its tricky interaction with Quartz.

J. White: Any developer that wants to maintain source and/or binaries on the Darwine project at SF.net is welcome to do so. I have responded to every such request that I have seen, which isn't to say of course that someone hasn't sent such a message that I haven't seen. Folks should be aware that you must subscribe to the list to post (although I do manually review posts from non-subscribers and try to put through any that are actually about Darwine and not male enhancement or get rich quick...). It is true that questions from users trying to run application X may not get much help other than being told Darwine isn't ready for end users.

Of course folks are also welcome to host their own builds, and I'd be happy if someone came along and just fixed the web site (which suffered greatly in the move back to SF.net from opendarwin.org - I didn't want to leave SF.net in the first place...), so we could point other folks to those builds.

It was never my intention that Darwine be a fork of Wine, but rather a friendly haven for Mac developers working on Wine. If that means doing more for users such as hosting binaries, then I'm fine with that too.


Adam noted: Latest WineQuartz.drv patch is 0.9.58. Is there any change for more recent release? I tried this patch with 1.0-1 however it has too many conflicts.It would be most convenient if you had just update http://repo.or.cz/w/wine/winequartzdrv.git to match 1.1.0 somehow and include Quartz.

R. Shearman Someone needs to do the work to resolve the conflicts that you just mentioned. CodeWeavers would get many more customers with a working quartz driver. The real reasons are technical. If they weren't then you would already find CrossOver 7.0 shipping with winequartz.drv, which it doesn't.

Emanual: I resolved conflicts for wine-1.0, but didn't take a look yet for wine-1.1.0, i just know that's some changes in user32 and winex11.drv have to be update in winequartz.drv too. I will see this week end if i can find free time to make a new patch for winequartz.drv and send it to SourceForge. (OpenGL is broken in winequartz.drv actually, because of a lack of time to fix it)

OSX and Codeweavers

All you conspiricy theorists, just relax. J. White posted about Codeweavers in March 08 on the wine devel lists:

We are very interested in Wine having a more native OS X interface. However, our analysis is that the task is difficult and will require a long time to stabilize and get right. I am excited by and interested in Emmanuel's work, but I am told not to be too excited, that it's not a magic bullet, and that the bulk of the hard work is still ahead. We have a long history of hiring proven Wine developers and thereby sponsoring their work. We do that as much as our income will allow, gated by peoples ability and willingness to work with us.

To answer the seemingly implied question: "Are we deliberately crippling Wine for Mac OS X to serve our own nefarious ends", the answer is no. That's in no small part because our main nefarious end is to improve Wine . Did we make a decision to focus on an X11 based solution for Mac OS X? Yes, for the time being. The advantages are that it's here now, works now, and that most of what we do now also benefits Linux and other platforms. The disadvantage, apparently, is that people suspect us of all kinds of nefarious plots... And, on a final note, just so its clear: the contract between CodeWeavers and Alexandre is very explicit: [...]CodeWeavers has no control over whether or not Emmanuel's code goes into Wine. That's entirely Alexandre's decision.

[Ed while not connected in any way to Codeweavers, A guess at translation would be this: They have to consider where to spend their time and pick their fights. While Codeweavers is not a bottomless pit they have done wonders for wine - just check the enormous number of patches they regularly submit back to Wine. You can support their efforts and Wine - if you have a business use for Wine - consider using the codeweavers version of wine]

Further Reading

Building from Source

There are a few steps for Darwine. One needed in Nov 08 was mentioned by J, McKenzie: FontForge is required to build Darwine. MacOSX does not come with the necessary parts to support TrueType fonts.

Troubleshooting

[Sept 08 wineuser]

err:wgl:X11DRV_ChoosePixelFormat No libGL on this box - disabling OpenGL support !

J. McKenzie: This is not a problem caused by Wine, but rather the X11 program under Leopard (MacOSX 10.5) does not support OpenGL 'out of the box'. There is a possible solution: Use the XQuartz version of X11. It is a simple process, visit the XQuartz MacOSForge web site. Select Releases and download XQuartz 2.3.0. Once the file completes downloading to your Mac, click on the disk image file. This will open to reveal two files: a package file and a folder which includes the readme and change log. Click on the package installer icon to start the installation. It is HIGHLY recommended that the installation be completed by a system administration account. Follow the prompts to install the software package. FWIW, approved XQuartz versions are used in future Leopard updates, you are installing the latest approved update ahead of the Leopard update schedule.

Retrieved from "http://wiki.jswindle.com/index.php/Apple"
Personal tools