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

Not much different from 68K-PPC conversion

[wowbagger]

If you think about it, this COULD be done in a manner simillar to the way Apple handled the 68K to PPC conversion:

You have BOCHS run the actual application code. When the code makes a call to one of Wine's libraries, you hit an escape sequence and drop to native PPC code for the actual implementation. At the end of the call, you resume emulation. It would probably require some changes in the shim layers between the DLL exports and the core Wine code, but it could be done.

That worked well for MacOS because applications spent most of their time in OS code (which was native PPC). How well it would work for Windows programs remains to be seen.

This has been kicked around a bin on Winedev.

Disclaimer: IAAWD (I AM a Wine developer, in my own small way - I did some cleanup on the Joystick and ADPCM audio code).

Not using Bochs...

[BlueSteel]

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.

"Slow" is relative

[fm6]

It's true that emulating a serious CPU takes a lot of crunching. Which is why we've traditionally relied on campatibility layers (like Wine) and hardware support. But like many other problems, this one is being nibbled at by increasing CPU specs.

When I want to play an old DOS game on my XP system, I don't mess with a compatibility layer (complicated and unreliable) or reboot to DOS (damned inconvenient). I run DOSBox, which emulates not just the CPU, but the sound card and video adapter as well! The overhead is horrendous (Sword of the Samurai takes more than half the cycles on my 1 Ghz Pentium III), but well within the capacity of my system. And that's a real-time application! I imagine the DOSBox would barely notice the overhead for something less CPU-intensive, like a word processor. One of these days, I'm going to have to try Windows 3.0...

I think most Windows desktop applications (database clients, productivity software) would have even less overhead than my old DOS games. But even if they had a lot more, consider the specs of a low-end Macintosh. Its CPU cycles as fast as my Dell's, and the raw crunching power of a G4 is possibly twice that of my PIII. Never mind a dual-processor G5!

Which isn't all that expensive. If performance and usability were the only criteria for buying a computer, I'd be a Mac fanatic. As it is, I hardly ever touch one. Oh well.

Re:This will be really slow

[addaon]

There's a LOT of reasons that 'all the java tricks' can't be applied; the main one is the different structure of memory. A few of the java tricks (dynamic recompilation, for example) can be; others (instruction reordering) can't be.