Slashdot Mirror

← Back to Stories (view on slashdot.org)

WINE for Mac OS X in Development

Posted by pudge on from the but-can-i-play-games-on-it dept.

TylerL82 writes "The Darwine Project aims to get WINE up and running through X11 on Mac OS X/Darwin. According to the site, WINE itself compiles rather well, and they'll be using Bochs for the actual x86 emulation. Quite an interesting idea. It's crazy, but it just might work!"

5 of 150 comments (clear)

  1. This will be really slow by NanoWit · · Score: 5, Insightful

    The reason we haven't seen WINE off of x86 yet is because like the name says "Wine Is Not an Emulator". So there's no code in wine that simulates the processor/real hardware. Bochs was just pitifully slow the few times that I used it. This won't have any kind of speed

    1. Re:This will be really slow by Joey+Patterson · · Score: 5, Funny

      there's no code in wine that simulates the processor/real hardware

      True that, but what about other solutions for running PC software on your Power Mac G5?

  2. Not using Bochs... by BlueSteel · · Score: 5, Interesting

    According to their FAQ, they aren't using Bochs for x86 emulation, but QEMU. I have no experience with QEMU, but according to some of the posts on Darwine's sourceforge message board, it's much much faster than Bochs. I wish these guys luck. I'd love to have wine running on OS X.

  3. Bochs? by CODiNE · · Score: 5, Informative

    I don't know where all this Bochs talk is coming from. I checked the FAQ and looked around some links and never saw it mentioned. QEMU on the other hand seems to be what they're putting in the official release. Maybe Bochs is in there for now for compatibility reasons. QEMU is waaaay faster than bochs, I can't wait til this is packaged up in a DMG that I can recommend to my OS X buddies.

    --
    Cwm, fjord-bank glyphs vext quiz
  4. Re:Two things by g_lightyear · · Score: 5, Informative

    Not necessarily. The technology being chosen is a combination of native code - which can do any necessary 'transitions' to a 'normal' endian mechanism at the API boundary between WINE and the application - and the emulator in question.

    The emulator in question is based on something similar to the FX! Alpha code recompiler; it provides an execution environment, yes, but also dynamically recompiles code into native.

    Between the core Windows libraries being "native" (in that they're wine lib, and therefore PPC-compiled native on OSX, not native x86) and the remainder in this 'recompiled' code execution environment, it's possible to strip out much of the endian issues.

    Not saying they will - only that there's a lot of room to manoeuvre here.

    Free.fr, where the project is hosted, is (of course) being slashdotted.

    One of the performance metrics lists the QEMU version of gzip (x86 on PPC) being 5 times slower than native (for example) - and comparison to bochs put bochs well behind (however, qemu had no MMU emulation).

    --
    -- A mind is a terrible thing.