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
What, is this a conspiracy to make Mac systems run more slowly?
Cool idea, I wish them the best, but I like apps to load within my lifetime...
Integrate Keynote and LaTeX
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.
.. to get a computer that DOESN'T run windows. One that is faster, more secure, runs a more stable OS and is more powerful, just so that you can emulate a PC so it's slower, and less stable. Weird.
DISCLAIMER: My only experience with using X11 on OS Xis running OpenOffice via it.
I am concerned that this will simply be too slow to be useful. Even with a 1Ghz G4, loading OO.o, which uses X11, is very slow (takes minutes to load). I could only imagine loading an exe via WINE via X11 via OS X would be an exercise in patience.
Any info on minimum system specs or performance levels the project is targetting. (I tried to RTFA but there was little substance.)
I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
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.
...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
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
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
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.
Let's see now:
x86 assembler instructions translated to PPC assembler instructions (two fundamentally different microarchitecture designs, CISC vs RISC and endian issues) using the Win32 API translated to Xlib (X Windowing System) talking to Apple's X Server translated to PDF commands and sent to Quartz.
Can you say "speed demon"? If you need to run Adobe Illustrator that badly, then at this sort of speed it'll probably be easier to decompile it, port it and recompile it!
will do anything to play minesweeper.
I dunno, I thought it was a pretty obvious one. I always thought that combining Bochs and Wine, and alleviating the emulator of the burden of hosting the entire OS, would be a great alternative to the painfully slow experience of trying to do anything under Virtual PC. I'm glad that somebody's finally trying to make it happen.
The To Do list shows 15 tasks, one guy working on 4 (one finnished), one on another, and 3 working on the most important one: Improving the Webpage. The rest has yet to be assigned.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
I thought it was a typo at first.
WINE is actually a good solution as it can run natively on PPC with very few problems. The x86 emulation is going to be a little rough, but it seems that they are going to work on a lot of the code themselves (QEMU isn't very PPC friendly yet)
Anyone know when WINE is getting ported to Windows?
The US government won't even sign the international land mine treaty! Mines kill a person every twenty minutes, are damn tough to clean up, the US spends hundreds of millions every year cleaning up American landmindes...
Some people really WILL do anything to play minesweeper.
-fred
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.
the think is people are not going to be buying zillions of these things. So it may well be affordable at say 100 or 200 dollars to just get a hardware device rather then a slow software emulation. Now youjust have to emulate the bios and map the mac's IO onto the PC.
Some drink at the fountain of knowledge. Others just gargle.
I've had this idea for a long time (and obviously I wasn't the only one), but I'm not skilled enough to do it. I'm glad somebody's doing it, and I can't wait to try it.
A previous poster said they didn't think it would be very fast. In VPC, the slowest stuff is graphics. A native Win32 API would handle graphics crap natively, which would be a heckuva lot faster, probably faster than VPC's special graphics driver approach. As to how much time most windows apps spend in the APIs, I wouldn't know... but consider that those APIs == everything: GUI, networking, file access, etc. The amount of stuff being done inside the emulation will most likely be much less than in VPC or bochs.
If they ever get DirectX (say from WineX) implemented... whoa.
Ron Paul 2012
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
Remember the old days when some Performas came with additional x86 chips and you could switch between Mac/Windows?
Granted, it's a tiny niche, but there's a lot of software my coworkers and I use that keeps us tied to Windows. For example:
- Texas Instruments Code Composer Studio IDE for their DSP products
- Altera's Quartus II IDE
- Cadence electronic design software (Orcad Capture, PSpice...)
- Analog Devices' VisualDSP++ IDE
I imagine many other tools in the embedded devices market are windows-only, too. It probably keeps costs down for companies like these to make their development software only available for the most ubiquitous platform. Annoying for those of us who wouldn't use windows otherwise, though, especially when the average cpu and memory requirements for many of these applications is rather low. Most of the time for me, these programs are just sitting idle while I read a schematic or pore over some code. I doubt they'd run much worse on an emulator.
I know it's a little childish to complain about the companies that choose an established platform with obviously stock IDE GUI elements to make their IDE that will sell in small numbers. They probably don't make a lot of money off of the IDE, as it's the chips that they sell in quantity. I don't blame them for their economic good sense, and they have enough problems with their single platform to begin with.
And I agree that a cheap $100 used PC would run most of the apps I would need it to, but that's not what I want. Windows has annoyed me enough over the years that I want to use something else now. Perhaps these guys feel similarly.
Oh, Adobe did Premiere for Mac up until the summer 2004 release of Premiere Pro (which was an all new product, really). You can still buy Premiere 6.5 for Mac, and it's Mac OS X native and everything. I still use it for things like it's very cool analyzer and bitrate graph.
My video compression blog
No so much from the perspective of getting apps running on the Mac, but from from the perspective of getting Apple interested in this way of getting apps running on the Mac.
From my understanding wine itself already compiles 100% PPC including wine dlls. Now all a developer has to do is port their own functions to PPC compilable code instead of rewrite from scratch.
A HUGE chunk of the work in a gui windows app is dealing with the win32api. Porting to the Mac means rewriting all this... now it doesn't, now if your own functions are fairly portable then your pretty much set. Write a mac installer that gives your app it's own personal wine world like winex point2play does and this can be completely transparent to the user.
Apple in the mac world is different than our overlord in the pc world. Apple as a hardware company wants all the software they can get running on the mac. If they don't have to write it and someone else offers it all the better.
This could mean apple working on the wine win32 api implementation, most of which carries over or is easily carried over to the x86 version.
Where's my choice for "-1, YOU MONSTER!!" moderation?
He turned the fastest massproduced computer on the planet into a WinTel! This moron reminds me about an idiot in High School who gloated about killing a cow by tipping her, while she slept, onto a sharp rock -- too bad when I called the police and SPCA, it was my word against his.
We should hire a taxidermist, an hitman, and a clockmaker, and then, kill him, gut him, and turn him into a Grandfatherclock!
Impeach Bush
Take a look at their forums where this question was asked: qemu, not bochs
The reason that it can be true that 1+1 > 2 is that very peculiar nonzero value of the + operator
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
Ok, I'm forming the angry mob right now. The torches and pitchforks are on me but I need someone to bring a bag of feathers and a bucket of tar. SIEZE THE CRETIN! Who's with me?
I tried "Indiana Jones" game demo on my mac, I did something freaky which I don't remember, game crashed and I saw some "wine" entries on OS log.
I am kind of newbie on mac, is there any explanation from oldtimers? Is that the same Wine? e.g. licensed version etc? Maybe its already done in house?
Oh there the game URL: http://www.aspyr.com/games.php/mac/indy/
What about his parents? If they don't know anything about computers in general, and their son's interests in particular, why on earth do they go out and buy this very expensive system? What about a $ 3000 CompUSA gift certificate, next time?
It seems to me that the entire family is highly dysfunctional, in addition to having way too much money.
Your local wholesaler will sell you an optical mouse for $3-$5. Keyboards are $1-$5 and video cards start at $5 (for the basic non-gaming kind). Cases cost $20 for the great ones. The fancy ones can pass $60. The cheap ones start at about $12. I'm not sure about memory or a drive, but your prices look way too high. I used to buy for a reseller; but the only difference in our price and the public price is the sales tax.
Leadman was one of our suppliers. Find one of their locations and you'll probably find a dozen competing wholesalers.
You can use a cheap PC with Windows, VNC, and SAMBA to get full PC functionality in your Mac for less than the cost of VPC. If you're using Wine and X11 anyway, you might as well skip on VNC and a copy of Windows and just use Wine on a Linux box with your Mac acting as an X11 server.
exaggeration (how the heck do you spell that, anyway?)
If you're ever unsure how to spell something, type it into google. If you spelled it wrong it'll say did you mean (correct spelling)? (Example)
Have you tried Linux yet?
I did. (I use google for everything, even my primary calculator; just waiting for it to do currency conversions.) It suggested my spelling was right, which I didn't quite believe.
I've had this sig for three days.