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!"
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
I'd love to see WINE on OS X but will it run any faster than Dosbox? I know you're thinking "Oh, great, he's comparing WINE to a game environment emulator." but hey, it's the same problem. Dosbox emulates a 286 or so wholesale, which is...well...useful for old DOS games, but can Wine promise anything more? WINE is, obviously, not an emulator, so it has to work on top of an actual emulator. Dosbox is slow. Bochs is slow. WINE is fast...on a high end x86. WINE won't run so well on your old 386. So if WINE is running on top of Bochs, is it like taking your Ferrari out for a spin in wet cement? ...or is soembody going to do some brilliant hacking that magically turns my G4 into an Athlon?...or a K6? ...P2? ...486?
"Life's funny sometimes." "And sometimes it isn't." --Cat's Cradle
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.
This is a really weird one, and it is difficult to say how fast or slow it might be.
Many of the core Win32 api's and DLL's have been re-implemented as Linux native equivalents as part of the wine project. If these are compiled as linux ppc versions, and you have an x86 emulator running the non-ppc bits, you get a really bizarre hybrid of code executing. It will be really interesting to see how this works. Its also pretty difficult to say how fast or slow this thing is going to be, due to the strange architecture. My brain is having a confusing time trying to figure out how they would string these components together.
Nonetheless, good luck to them, its an ambitious project and probably has some far reaching implications for the future.
Electronic Music Made Using Linux http://soundcloud.com/polyp
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.
Does it really need to emulate the win32s stuff. What would the performance be if the win32s stuff ran native on PPC and just ran an x86 emulator for the nonWINE .dlls and application code. All of the screen & IO API could be PPC native. The endian thunking layer may munge everything and destroy the speed though....
Now I hope and pray that I will But today I am still, just a bill
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.
I've had this sig for three days.
There is but One Rule for computational speed: "To make it go faster, make it do less."
WINE is smart because it re-implements many Windows DLLs natively. QEMU is smart because it caches and executes native code built from x86 code. Taken together the speed should be noticeably better than VirtualPC.
But the most optimal method by far would be to convert x86 binaries into PPC application packages that link to native libraries / frameworks corresponding to Windows DLLs. Such translated binaries would require no emulation layer, just the presence of the necessary libraries.
But can you imagine how complex it would be to convert x86 code into PPC code? And yet part of me thinks this brute-force method is almost trivial. It's simple enough to disassemble machine language. And one could certainly disassemble x86 code into a working C equivalent where C variables correspond to x86 registers.
Besides the fact that this would be an exacting and laborious task, what other barriers exist for this approach?
-- thinkyhead software and media
Switching order on the PPC is a breeze, it does it on the fly and does it extremely well.
VirtualPC does this, its one of the major improvements they put in to it which is why the more recient versions are so much faster than the previous versions.