Slashdot Mirror
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!"
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
Actually, this might work out OK -- from their site, Bochs is going to be stripped down (no interface, no SDL, etc) and /just/ provide x86 emulation -- sort of like a software processor. Yes, it will not provide native speed, but it might just be "good enough"....
10b||~10b -- aah, what a question!
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).
www.eFax.com are spammers
All problems in Computer Science can be solved by adding another layer of indirection.
Ceci n'est pas une signature.
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.
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
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.
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.
> 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.)
will do anything to play minesweeper.
You are not alone. This is not normal. None of this is normal.