WINE for Mac OS X in Development

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!"

Comments

Bochs?

[CODiNE]

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.

Re:Two things

[g_lightyear]

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

Re:Two things

[clem.dickey]

> the bit-order is going to have to be switched (different endians). This is not fast on a good day

That's byte order, not bit order.

Even on a bad day dealing with byte-reversed integers on a PPC requires just two instructions: Load Byte Reversed and Store Byte Reversed. These replace the Load and Store which PPC uses for native data.

Floating point load/store would suffer, though. You would have to use the integer unit to reverse the bytes, as there is no Load/Store Float Byte Reversed.

Note that data in a PPC register has no endianness, because PPC registers, unlike PPC memory, do not provide byte or bit addressability. (The original POWER processor have an "extract bit" instruction which extracted a bit at (big-endian) position n in a register. This instruction was not carried forward to the PPC.)

Re:Not using Bochs...

[nathanh]

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.

The reason QEMU is faster is because of dynamic translation.

Bochs decodes each and every instruction just before it is executed. So if you have a loop that executes 100 times, you have to decode the same instructions 100 times. That's incredibly slow. I have seen estimates that Bochs needs 160,000 native CPU instructions to emulate a single x86 instruction.

QEMU takes a block of code (typically a whole page) and translates the block into the native instruction set. Then it executes the translated block of code. QEMU tries to keep translated blocks around as long as possible, using dirty bits to determine when retranslation is needed. This is the same technique used by VirtualPC on the Macintosh. It is much faster than Bochs!

There is experimental code in Plex86 to do dynamic translation and Bochs can use Plex86 as the backend (it offloads entire pages of code to Plex86). So it's possible that Bochs will one day achieve the performance of QEMU.

Take note that QEMU is usable today, just so long as you're running purely Linux binaries. It is possible to use QEMU to run Linux/x86 binaries on Linux/PPC for example. QEMU's dynamic translation engine is pretty decent. QEMU doesn't emulate the PC hardware. Bochs does emulate the PC hardware. If you could cherry pick the dynamic translation from QEMU and the PC hardware emulation from Bochs then you'd have something to compete with VirtualPC right now.

Re:wwwwoooorrrrrkkkkk

[squiggleslash]

It just might work... but veeeeeeery slowly, if Bochs is underneath it.

While the write-up says:

According to the site, WINE itself compiles rather well, and they'll be using Bochs for the actual x86 emulation.

The FAQ says:

The second phase is to then integrate in WINE the QEMU binary translator.

Additional supporting tools for launching Windows applications from the desktop and an integrated installer are desireable items for the package (like OpenOffice is doing).

This is distinguished from simply using QEMU to run Windows because there is no Windows here. Just WINE and QEMU to run Windows applications directly under X. That will enable vastly better performance, better integration, and easier administration.

For Mac OS X, the ideal would be to eventually use the native GUI.

Further enhancements could include integrated support for things like FAT32/NTFS volumes with Windows under via QEMU (or other PC emulator) so that the same Windows applications could be run in either mode (Windows or WINE).

My understanding is QEMU has a fairly good reputation, though that might simply be because it doesn't have the overhead of emulating VGA/etc.