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."
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. The following is the transcribed dialog of our conversation.
--
osViews: "Could you summarize what the Darwine project is and what you hope to accomplish with it?"
Jim White: "Darwine was an inspiration that occurred when I saw the development of BOCHS come along. I thought, 'wouldn't it be brilliant if you could take wine and instead of emulating an entire operating system, which struck me as being a terrible waste, be able to run Windows applications directly under the Mac operating system without having to virtualize the whole separate operating system environment.'"
osViews: At some time you must have come across the fact that BOCHS is not necessarily the fastest emulator.
Jim White: Right! So the next thing that comes along is QEMU. Rather than using a naive interpreter like BOCHS which is an instruction compiler, [we opted for] a nice modern emulator design. That's what the guys working on Darwine are doing. In fact, the lead developer for Darwine has just completed porting QEMU to OS X.
osViews: I haven't used QEMU. How much faster is that as compared to BOCHS?
Jim White: Well, everybody is always asking performance questions and of course they're hard to quantify, but people are reporting pleasing results using QEMU. In fact I was just reading a [web discussion] thread where the people were saying that its obviously slower than Virtual PC but respectable.
osViews: I would imagine that would get better as it became more established.
Jim White: Well, thats exactly the point. QEMU is an open source effort with quite a bit of support and interest so we certainly expect to see QEMU get to be pretty darn good.
The key part to WINE is an implementation of the Win32 API. That portion is called WineLib. Thats a big chunk of the work that goes into WINE to make it do all of the Windows function calls. Those are the function calls that are like Windows.
Wine is primarily running on Linux and XWindows and they support a few operating systems like BSD. So under Linux, XWindows is the standard graphics environment. On OS X, we've got good XWindows, which is well supported but it gives a pretty ugly looking result. You don't get the type of applications that Mac users would like to have.
So there's two large areas of development yet to be done in addition to incorporating the x86 emulation directly into the Wine environment itself, there's the moving off of XWindows for graphics and moving onto Aqua using the native OS X graphics.
osViews: There's been some speculation that Apple has offered certain elements of code to the Darwine project.
Jim White: I'm not aware of any support that we received from Apple at all other than Darwin, which is the core of the OS X operating system and is open source.
When we initially opened up on Sourceforge, the lead developers had talked to the opendarwin.org people. We wanted to go host there, so we moved the web hosting and CVS to opendarwin.org. So Darwine is an Opendarwin project. Many of the key developers on Open Darwin are mostly Apple employees, but Darwine hasn't received any direct Apple support.
osViews: I'm sure you're probably familiar with the effort that IBM and Microsoft had years back when they were in a partnership together at a time when IBM was developing OS/2 Warp.
Jim White: Yeah.
osViews: Its largely believed that one of the reasons why OS/2 was adopted poorly is because people are less inclined to port their software to IBM's programming environment when they could do it entirely within Micros
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.
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
isn't it a pretty useless project then?
like, not totally useless.. but pretty much. the reasoning being that app makers won't bother making such a port..
well, if they just want some opensource windows only programs ported more easier maybe then..
world was created 5 seconds before this post as it is.
...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
If you've got the source code, then it's probably not that hard to port it to GNUStep. You'll need to translate the .nib files (UI definitions), but you'll probably need to tweak the UI when not running on a Mac anyway if you want it to have a consistent look and feel with the rest of the platform. Currently GNUStep's implementation of Foundation and AppKit are fairly complete, and applications that only depend on these can be moved fairly easily between GNUStep and OS X. The biggest problem is that the non-Apple version of gcc doesn't support Objective-C++, so if your application mixes Objective-C and C++ (as is the case in WebKit, where the core is C++ but the interface is Obj-C) then you will not be able to compile it.
I am TheRaven on Soylent News
Its bad enough that Metal and Aqua are mixed interchangably without any rhyme or reason...mix in X11 apps and now Windows apps and I think we can safely say that visual consistency in OSX is gone.
There is actually supposed to be some rhyme and reason to the Aqua/Metal looks in OSX:
Apple Human Interface Guidelines
See the section on Windows -> Window Appearance -> Brushed Metal Windows
However, if developers choose not to adhere to these guidelines, there's little that can be done, unless the apps get hacked. Turning on metal is as simple as toggling a switch in XCode and Interface builder. You can disable the metal look in Safari by editing it's preferences as well...
Try Mac On Linux (Like vmware for PPC, PPCLinux only obviously)
Or try Sheep Shaver, a portable PPC emulator, although they admit to not being able to run OS X yet. (And you still need a PPC ROM image)
Why aren't you encrypting your e-mail?
And this helps them sell Apple hardware, how, exactly?
[
Sure, there's MySQL etc, but if you have to have Access, you have to have Windows.
Never shake hands with a man you meet in a fertility clinic.
Well, it would help them sell iPods to me, since I have no Mac and refuse to use Windows.
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.
There are quite a lot of people that used to be Linux users, but have adopted OS X as a better form of Unix. I'd imagine a fair proportion of them are programmers.
My parents won't switch to the Mac because their stock charting software (from some tiny company in Michigan) only runs under Windows. Probably not representative of most people's needs, but then again, maybe a lot of people have one or two obscure apps they need to run?
How about the many games that are released on Windows but will never see the light of day on the Mac, such as:
* All of the Elder Scrolls games (Arena, Daggerfall, Morrowind, Battlespire, Redguard)
* All of the Grand Theft Auto games
* All of the Half-Life games
* All of the post-FF VI Final Fantasy games
* All of EA's non-golf sports games
* Most of the Ultima games
* Deus Ex: Invisible War
* Dark Age of Camelot (and most other MMORPG games)
* And hundreds more that I'm forgetting right now...
It would also help for games that are released on the Mac, but are massively late (e.g. Neverwinter Nights and Star Wars: KotOR).
Donate free food here
It is sad that even on slashdot this question is still ask.
Why do they do it?
Because they can.
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.)
People will start understanding good UI when they realize that a skin!=good UI.
The OS X Metal look is rarely good UI, unfortunately.
Why yes, I AM a rocket scientist!
Like what? What is there that easily allows people to create databases that exist as a single file, which can be sent to others in email and opened without any setup at all?
It will be running QEMU, an emulator, that will be closely tied to Winelib, which will then run Windows executables.
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
Even Microsoft realizes Access is a piece of shit. In the MSDN article on pricing software from Friday, the guy used Access as an example of a program that would be VERY valuable if replaced by a better interface with plugins to an open source database.
And yes, there is an open source JDBC driver for Access. But it is so poorly supported (by developers that have no time to even write documenation of how to use it and who don't speak English) that you are much better off dropping $100 or so on one of the commercial replacements or writing your own.
Hey freaks: now you're ju
I'm not sure that these are good examples.
Core engineering applications are
1) Vital to the success of the products you are engineering
2) Usually the worst citizens in the Windows world, so they are the hardest to emulate.
3) Dwarf Windows in cost.
Who in their right mind is going to run a critical engineering app in an emulator?
1) Run into any issue, call up the CAD vendor and have them say "we don't support running it on anything but real 100% windows....click, dial tone,..."
2) Make critical engineering work depend on the least-used portions of the emulator, written by random open-source jockey, and only lightly tested by the thousands of teenage users who mainly use it to run video games.
3) Save the cost of a $500 Windows license, while still spending $30,000 on a CAD license, and $100+k/year on the engineer. Penny wise, pound utterly stupid.
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.
Filemaker Pro, availible for everything from the Palm to the PC.
HTH
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).