Slashdot Mirror
Interview - Jim White of the Darwine project
Kelly McNeill writes "The Darwine project intends to port and develop Wine as well as other supporting tools that will allow Darwin and Mac OS X users to run Windows Applications. It is an open source project led by a growing number of developers including Emmanuel Maillard, Pierre d'Herbemont and Sanjay Connare. osOpinion/osViews had the privilege to speak to with the project's administrator, (Jim White) to tell us more about Darwine and where the project is headed. For those that don't know, Darwine is Wine (Wine Is Not an Emulator) for OS X on PPC. The following is the transcribed dialog of their conversation which is also available in an audible format on osRadio.com."
WINE is not an emulator....yet....on...a...ppc.....uh...isn't it actually an emulator? The idea behind WINE is that it puts a wrapper on native calls.....x86 instructions are x86 instructions....so DarWINE is more like, DarWISAE, because it is "sort of an emulator...."
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
How about a way to run Max OSX apps in Linux???
I'm serious. It would be only fair since Wine is written to run Windows apps on an OS that Microsoft didn't intend.
-b
Apps are not running natively:
"Developers should be able to recompile their Win32 Apps using WineLib and make them work in Mac OS X..."
The only app I still really use on my windows box is MS Money, and that's only because quicken for mac is horrid. If I could get that over on my powerbook, I'd be in heaven.
--
From the website: "We are currently working on integrating an x86 emulator in wine in order to run Win32 exe on a PowerPC Box. But on Darwin-x86 a Win32 .exe should run within wine" http://darwine.opendarwin.org/faq.php#5
:-)
So yeah it will involve an emulator on PPC but remember that Darwin is also on x86. So WINE will still be NE but will be used in conjunction with something that IE (is an emulator).
I thought wine only simulated the Windows API calls, so you still need to be running the program on the native windows cpu, x86. Can someone explain how this works on PPC?
Do you realize that in less time than it took for you to write your questions, you could have clicked the link and saw that it uses QEMU to map x86 to PPC instruction calls.
It didn't even require a 'googling' on your part, just a click.
QEMU...
A house divided against itself cannot stand.
What programs for MS Windows, other than Office/Outlook are needed? And since MS Office is available for OS X...
This seems like a solution looking for a problem to me.
Of course the paucity of applications must be addressed in some manner - its quite clear that many ISVs are not addressing OSX or have any plans on doing so as it meanders around 3% market share.
I'm continually amazed at how OSX has reached the unassailable status of Google, Linus, etc in the /. mindspace. My wife purchased a new system that manifested numerous oddities and inconsistencies that I would have though Apple would have dealt with. For starters - a second disk installed by Apple for which my wife did not have write access. Duh! Make preinstalled hardware work the way users think it should. When she went to repair this, I was asked "what is group wheel?" To which I replied it is something a Mac user should never have to know about. The unix stuff is still showing up in odd places.
Just what I needed, a way to run crappy Windows apps on OS X!
irb(main):001:0>
It fails to run a lot of popular software right out of the box. Last I checked, it wouldn't install IE6. Now now....before I am crusified, I have no love for IE. But it is a simple fact that many programs are built on top of it; many industry specific programs such as banking and financial programs.
.Net would also be a godsend since more of the newer windows software is starting to rely on it.
There's also the famed Photoshop incompatibility, that crossover has managed to overcome. When will the code be incorporated back into Wine?
I realize Mac users have no need for a Windows version of photoshop, but I wonder if Darwin is going to be able to overcome the obstacles that Wine has not been able to.
Support for
Mod points are pointless when you browse at -1.
Wine emulates Win32 function calls. A second application QEMU emulates the Intel 386 instruction set and hardware environment. So a Mac can emulate an Intel PC.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
...it'll most likely be limited to Linux PPC. The problem is emulating a PPC processor on x86 hardware. It is much harder than the other way around.
Kjella
Live today, because you never know what tomorrow brings
"The second phase is to then integrate in WINE the QEMU binary translator."
that comes later then.
world was created 5 seconds before this post as it is.
... is on a Windows machine.
I have a Windows box with XP Pro to which I connect using Microsoft Remote Desktop Client for Mac (There's a port of the OSS RDesktop app available too).
Bearing in mind how cheaply one can acquire an x86 PC capable of reasonable performance (no app run over remote desktop will ever be *fast*), this has to be the most efficient way for users of low-powered macs to run Windows apps.
You can even full-screen it and freak out your mac-addict friends by showing them a Mac with, apparently, Windows installed on it.
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
And this helps them sell Apple hardware, how, exactly?
[
Well, it would help them sell iPods to me, since I have no Mac and refuse to use Windows.
Recompile with WineLib is what they mostly have working now. They ARE integrating an emmulator to allow the execution of x86 binaries. But that is not ready for use.
According to their FAQ they are integrating a binary translator called QEMU. Their intention seems to be to have the wine libraries native and have them talk to the windows app (still x86) through qemu. This sounds like an interesting idea, especially if their additions to wine and qemu are integrated into the main trees. Then linux on other architectures could likely take advantage (if qemu has been/is ported to that architecture).
I'd much rather run OSX on Windows than Windows on OSX.
Anybody doing this kind of thing?
The idea for as I understand it is this:
... overhead city), Darwine allows applications to run essentially linked to native code - Wine/WineLib for PPC.
When the project is complete, OS X users will be able to open EXE files with Darwine. Darwine will use QEMU to execute the x86 instructions, however when the program makes calls to the Windows API, Darwine calls those functions in WineLib compiled natively for PPC.
So, where Bochs and VirtualPC and others like them emulate the entire operating system environment (Emulated BIOS, emulated hardware, emulated Windows, and finally the emulated x86 application
Thus for most Windows applications, the GUI and event handling and everything else the Windows API is good for will be executed in native PPC code. QEMU will then emulate an x86 processor for all the compiled code in the application.
Imagine some internal corporate application that uses all standard Windows widgets to let a user interact with some data: all those widgets plus the menu and root pane will be handled by the native WineLib code except when the programmer has included some special functions or number-crunching routines that are emulated on QEMU's fake x86.
Think about it -- It's a lot better than having an entire emulated instance of Windows 98 (and maybe even an actual x86 box) to do the same thing.
It would be nice if the developers are working along a path with modest but useful goals. It would be great if Windows-only drivers for various devices would run under Darwine. Such drivers would require less than the full Windows-emulated environment and probably no GUI stuff. So, it would be a more modest amount of work, yet still be of significant use. I also think they are not speed critical (most of the time).
Bert
Did that say Port Wine?
Maybe I need to cut back on the Monday morning drinking.
EphPod.
There, now you can have an iPod too.
Donate free food here
Dude, google for OpenStep and GNUStep. Your wish has been granted. That'll be five bucks.
I'm a leaf on the wind. Watch how I soar.
As they say on the web site, a native Mac OS X GUI is planned, but that's for later. I'm not sure wether I would really want that. IMO, Windows/Linux GUIs which are converted into a Mac OS X GUI look terrible. Those GUIs don't adhere to the Human Interface Guidelines. Even if they have the Aqua stuff, they still don't look like a Mac OS X app. Doesn't feel like one either. (Yes, I've been called a HIG tyrant before. You don't need to do that anymore. Thanks.)
So the WINE in DarWINE can't stand for "Wine Is Not an Emulator" because, well, it sorta is? No problem - just change what the letters stand for! I suggest:
Wine Isn't Not an Emulator
Wine Is Now an Emulator
Wine on os x Is doing some New things, possibly including a bit of Emulation
It seems like this project is limited by QEMU, which as far as I know, doesn't emulate x86 on a G5. Is such emulation really as hard as Microsoft makes it out to be? And do we have a chance of seeing Darwine run on a G5 anytime soon?
LinuxPPC users can already use MacOnLinux to run MacOS X and all its apps natively in the Linux environment, with almost perfect compatibility.
"I like systems, their application excepted", George Sand (French)
Well, GNUStep runs on top of x11. I was thinking about a project that would also replace x11 completely with Quartz backend.
Then you're not talking about cloning Cocoa, you're talking about cloning Quartz. Huge difference.
Start with GNUStep and GhostScript, and work from there.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Rather than be able to run an emulated X86 app on a Mac, wouldn't it be better to make it easy to build a native mac app using winelib?
A few tweaks here and there for byte ordering stuff, and presto, a native Mac app. Plus you could have conditional logic to be even more mac-like. No drive letters, etc.
Any good reason not to take this approach?
Posted from my Android phone. Oh, I can change this? There, that's better...
And I'm sure when you're willing to purchase 10 or 20 thousand iPods, they'll be more than willing to port iTunes to Linux.
Otherwise, it wouldn't be worth the development time, the support calls or the advertisement.
There just aren't that many Linux users period, even fewer who use a particular desktop toolkit (GNOME or KDE) and even fewer who would buy the iPod even if iTunes for Linux was available. If there's no money, there's no reason to port.
Besides, there are dozens of iPod management tools for Linux. Why not use one of those if you really want one? It's not like Apple's dogged support of market leading software platforms is preventing you from doing pretty much whatever you want with an iPod on Linux, BSD, PocketPC or whatever you like.
Hey freaks: now you're ju
do you realize that an AC just got a +5 insightful?
although repeted elsewhere this should answer your question:
wine is split into two parts.
wine the program loader - the part you use to run windows binaries on linux is close to an emulator. Really just more like a binary format like elf or a.out that is run in user space rather than kernel space.
libwine is the library used to port the windows api to Linux. it is similar to gtk or qt in that it allows a program to make winapi calls and they get translated to the appropriate X calls similar to any of the other Linux GUI libs.
wine the program loader wouldn't be very useful on OSX because there probably isn't many apps for the windows ppc port. libwine on the other had will allow the easy porting of windows applications to OSX or Linux. So far this hasn't been exploited as much as it should be, mainly due to the wine folks wanting a perfect 1.0 release, when they may be better off getting what they have so far as stable as they can and doing a 1.0 release with X features supported and Y features not supported. then go from there. (their project their decision though)
Paying taxes to buy civilization is like paying a hooker to buy love.
That's really the whole cathedral vs Bizarre issue. 'Gee, should there only be one true way of getting things done?
I, for one, will always take the Bizarre approach.
Share and Enjoy!
So, does this qualify as a security hole ?
After all, if this works well, then Mac users will get to enjoy all the Windows security holes...
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Well it seemed really useful, but of course I followed the directions and installed the programs to run exe files on OS X, installing the necessary X11 package. So I tried all the example exe files and, no dice. All it does is say it can't find the graphic drivers I just installed, something about X Server, then quits.
I'm just gonna check back when it actually works.
I am NOT a number! I am a - oh wait, I'm number 761710. Look! 761710!
Actually, I have to agree. Making Windows emulated apps sort of behave like Mac OS X ones wold be counter productive. Windows apps need the visual identification so that you know that they are something special and need to be treated differently.
For example, windows dialogues. People used to the mac dialogues know that they are well written, with simple precise wording and trivial button selections and usually the non-destructive choice as the default. ie "Would you like to cancel? No cancel". In the windows world dialogue boxes are often much harder to understand with complex wordage, double negatives and non-trivial buttons, ie "Would you like to cancel? Cancel Yes" (last one is a real dialogue box, google for it).
There are other things in the Windows world (for example where preferences settings are selected in Menus, no Application menu, etc) which are all different to the way Macs do things and a different interface (like classic is different to Aqua) give the user a learnable visual identification so that they can easily parragram shift to the correct UI guidelines for the correct program quickly and easily (most probably sub-consciously).