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!"
It just might work... but veeeeeeery slowly, if Bochs is underneath it.
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
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
Virtual PC may run reasonably quickly (still not what I'd call 'fast'), but that's because it used a horrible hack. All PPC processors up to and NOT including the G5 were bi-endian. VPC switched their endianness while it was running so it could do everything without swapping bytes. This is both the delay to further VPC releases and the reason x86 emulators will remain quite slow.
...that might throw a wrench in that, even assuming the apps do spend their time in system calls.
0) The PowerPC was an order of magnitude faster than 68k series. IIRC the 601 had twice the clock and was faster per clock than the 68040. There is no such advantage here.
1) In order to handle everything correctly here the bit-order is going to have to be switched (different endians). This is not fast on a good day.
Integrate Keynote and LaTeX
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
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.
will do anything to play minesweeper.
Unfortunately, this write-up is totally screwed up. The intended emulator is QEMU, which can already be used on PPC/Linux to run Wine at speeds aproaching native speeds. I posted a link to the forum where this is discussed elsewhere, but here it is again.
QEMU is a dynamic translator that decompiles x86 executables and recompiles them into PPC, caching the results. You can find the qemu project here.
Not only will this work, but it will work FAST. In fact, it will probably even be possible to drop windows DLLs onto your mac in the same way that you drop them onto Linux in order to get Wine to work better (using native windows DLLs instead of Wine clean-room versions). Remember, QEMU is a dynamic translator.
The reason that it can be true that 1+1 > 2 is that very peculiar nonzero value of the + operator
As it's been said here, Wine is not an emulator. The reason it works as well as it does is BECAUSE it's running on x86 hardware. Having it emulate x86 is going to really bog it down. I seriously doubt it will work better than VirtualPC. However, if they can get hardware vidoe acceleration working, then it might just be worth it.
Video acceleration comes free, through a few layers of abstraction. Basically, the windows program will call some Win32 API function
FooDrawTextlpsz(string);
The CPU emulator runs along fine and dandy until it hits this point, and needs to jump to the Win32 native API code. It calls WINE for this.
WINE is a natively compiled PPC application / library, so FooDrawText is just native compiled PPC code.
WINE takes the Win32 function, and uses an Xlib equivalent. XFooMakeStringGetDrawn(string, MONACO) or whatever.
The X server takes this Xlib call, and passes it to the Aqua drawing system, because on Mac OS X, the X Server is just an Application running alongside other native Apps.
So, Aqua draws the text into the window at the correct position, just as windows would on a native system.
This window is treated as a texture object.
The texture is used by the Quartz Compositing engine to draw the window to the screen by using OpenGL.
OpenGL takes the instructions to draw the windows, and hands them off to the video driver.
The video driver then instructs the card to finally draw the window onto the screen, using native commands for the specific card.
Lo and behold, the X86 Win32 request to draw text has resulted in a picture of some letters in our frame buffer.
Egad, I should probably take up baking.
So, anyhow, my point is that the Wine/ppc guys don't need to write an emulator for the video hardware. Though it's heavily abstracted, they get video acceleration for free thanks to the existing Xlib code. The Win32 application never touches the actual video device - it just makes API calls which make things happen to the hardware. Now, if this were a DOS emulator, it'd be completely different. You would need to actually emulate a VGA card that the program can have to itself.