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."

Comments

Confused....

[Vengie]

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...."

Re:Confused....

[TheRealMindChild]

Heh... there HAS to be code to CALL these functions. This code is good old x86. Else, I could run my windows binaries on ... say Windows NT for Alpha. If that were the case, why is there a whole Visual Studio for Alpha Platform?

Re:Confused....

[Vengie]

Let me Clarify myself. If you read the article, you notice DarWINE combines WINE with a back-end emulator. The package, as it stands, is a syscall wrapper along with a back-end emulator. Hence, DarWINE *is* partially an emulator. [and the fun recursive acronym isnt as appropriate]

Re:Confused....

[ShadeARG]

Hmm.. WINE Is Now an Emulator? It still works.

Re:Confused....

[arose]

Yes it does, but it's slower. :-D

Re:Confused....

[ArsonSmith]

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)

I got a better idea!

[El_Ge_Ex]

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

Re:I got a better idea!

[TheRaven64]

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.

Re:I got a better idea!

[dmayle]

How about a way to run Max OSX apps in Linux???

Well, if you're on a PPC architecture already, there's Mac-On-Linux. Though, I'm sure that by the tone of your comment, you actually meant x86. Well, ask and you shall receive. For the x86 folks (or just about anyone on Linux), there's PearPC. And you know what? They're both open source...

Re:I got a better idea!

[RAMMS EIN]

NetBSD is working on Darwin binary compatibility. Something similar could be attempted by Linux.

Re:I got a better idea!

[NoMoreNicksLeft]

Besides, linux users would have to emulate the ppc instruction set

Only for linux on x86. Why does everyone assume that's the only place you'll ever find linux?

Re:I got a better idea!

[BasilBrush]

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.

Re:I got a better idea!

[El_Ge_Ex]

Motion, iMovie, Final Cut Pro, etc...

One could argue that there are PC apps that have the same purpose as these apps, but some are merely adequate while others are near offensive.

(Shake would be included too, if it weren't for the fact it was a Linux app before it ever was a Mac OSX app. Still, the Linux version likely won't see updates anymore.)

Re:I got a better idea!

[mrchaotica]

Another poster already mentioned GNUStep, so I won't talk about that. But what he didn't mention is that OS X has support for "fat" binaries, that include both x86 and PPC code (or any other arch, for that matter). This means that a fat GNUStep/Cocoa binary should be able to run on OS X and some x86 platform (like Linux or FreeBSD, or even Windows) without a recompile. All the second platform needs is support for fat binaries as well.

In light of all the excitement over C#/Mono, It's sad that nobody knows about this.

Read the site

[Alex Reynolds]

Apps are not running natively:

"Developers should be able to recompile their Win32 Apps using WineLib and make them work in Mac OS X..."

Clarification

[torstenvl]

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). :-)

Re:Huh?

[Anonymous Coward]

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.

The emulator part is...

[pedestrian crossing]

QEMU...

Is there really a need?

[HogGeek]

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.

Re:Is there really a need?

[LiquidCoooled]

Gator, Mydoom, Welchia, CWS, Sobig, Nimda.

Did I miss any out ;)

Re:Is there really a need?

[molarmass192]

if you have to have Access, you have to have Windows

I feel bad for anybody forced to use Access, it's an utter POS. There are way way WAY better personal databases than Access out there. That said, the strength of Access isn't its' db engine but rather it's Crystal Reports like interface that doesn't really require any underpinning DB knowledge to use so I can understand the attraction. As a total side note, are there any level 3+ *open source or free* MS Access JDBC drivers??? I found a bunch of proprietary implementations but nothing redistributable.

Re:Is there really a need?

[Anonymous Coward]

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?

Re:Is there really a need?

[burns210]

It is sad that even on slashdot this question is still ask.

Why do they do it?

Because they can.

Re:Is there really a need?

[micromoog]

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?

Re:Is there really a need?

[dasmegabyte]

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.

Re:Is there really a need?

[ArsonSmith]

Working for a large chain of hospital's data center we have over 210 database front ends for over 160 different locations. These are applications that my not even have source code still in existence due to the original vendors going out of business, changing owners, or just plain lost it. to recode these from scratch would be a huge undertaking.

Wine allows us to run these applications on Linux/x86. although this wouldn't be of much use for OSX wine is a very useful program and Office/Outlook are more like benchmarks rather than needed applications. with OpenOffice and evolution there is little to no need for Office and Outlook, there is a need for the hundreds of small un-replaceable un-portable applications.

I just realized this doesn't really answer your concern, but still I think it is good information so I will post it anyway.

More pollution of OSX UI

[Ars-Fartsica]

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.

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.

Re:More pollution of OSX UI

[agby]

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...

Re:More pollution of OSX UI

[TheRaven64]

I would hope that Windows apps running in Darwine would continue to look like Windows apps (although drawn directly with Quartz rather than X11 on top of Quartz would be nice). Even if it is possible to use native widgets, the result will be applications that look like OS X apps, but don't feel like them. Leaving them looking like Windows apps will provide a visual clue to the user that they should not expect the application to behave like an OS X native one. It will also serve to encourage companies to produce native ports, rather than believing that running the Windows version in an emulator is good enough for anything other than legacy apps.

Re:More pollution of OSX UI

[Moofie]

People will start understanding good UI when they realize that a skin!=good UI.

The OS X Metal look is rarely good UI, unfortunately.

Re:More pollution of OSX UI

[dasmegabyte]

They don't act the same...not QUITE, anyway. The big difference is in handling the window. Aqua applications can only be moved around using their toolbar. Metal applications can be moved around by grabbing any part of the metal surface.

The whole POINT of this is that it is good UI to allow a person to manage a window using as much of the non-dynamic visual real estate as possible. But there's no way for a user to know what's dynamic and what's static.

This is what the metal look acheives. It says, "Hey, this part of the screen is not for user entry. So you can grab it." It is intended for data management forms and application launcher forms that have mostly static content aras -- programs that are mostly for dynamic user managed information (such as Word document windows, etc) should really be Aqua, because you're going to want to use as much of the screen as possible for user information.

I like the idea of Metal (because I like the idea of using otherwise useless space as a way to get a grip on the window), but I will admit it's damned confusing the way some windows CHANGE their L&F when their context changes. For example, if you close the toolbar on a Finder window (using the bubble in the upper right hand side), the window's L&F changes. It's a real WTF moment, especially since I don't consider the document source selector on the left hand side of the screen to be a toolbar.

I will not argue whether aqua or metal is the nicer interface. It doesn't really matter to me...they're both simple, monochrome designs that abstract the utilitarian nature of windows from the work inside them. They're pleasant without overshadowing the importance of the controls inside them.

Wonderful...

[transient]

Just what I needed, a way to run crappy Windows apps on OS X!

Wine is a godsend....but.....

[Savet Hegar]

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.

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 .Net would also be a godsend since more of the newer windows software is starting to rely on it.

Re:Wine is a godsend....but.....

[datadriven]

I have Photoshop 6 running pretty well on my slack laptop with wine 20040716, but couldn't get Photoshop 7 running.

Re:Huh?

[mikael]

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.

Trouble is...

[Kjella]

...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

Re:Trouble is...

[BasilBrush]

You have a point. But there is an alternative. Do an OS X API emulation, and get the software authors to do a recompile for X86 Linux.

If you think about it, the main difficulty of getting Windows software companies to provide a Linux version is the tiny market share of Linux compared to Windows. However, companies that are producing software for the Mac are already serving a 3% market share plaform. If they can reasonably easily do an X86 build for Linux, they could almost double their potential market.

Re:Trouble is...

[jaoswald]

The most commonly mentioned difficulty is the number of registers in PPC vs. x86. RISC instruction set architectures like PPC tend to have a relatively large number of general purpose registers, vs CISC ISA's which have a smaller number of registers, some of which have special purposes. (CX for count, SI, DI for offset indices, ..., my x86 knowledge is VERY stale, so I'll be vague from here on)

In emulation, to keep things fast, you would like to dedicate one hardware register for each emulated register, plus you need hardware registers to actually run the emulator!

A RISC ISA emulating a CISC ISA will enough registers to do so. (r1 = AX, r2 = BX, ..., r17..r32 available) The CISC ISA emulating the RISC will tend to

1) need to use the most flexible registers (AX) to run the emulator (e.g. load the RISC opcode from RAM into AX, extract the opcode field, compare it to your opcode table, and dispatch, because AX has the best support for bit operations, let's say)

2) also use the special-purpose registers to run the emulator (e.g. use an index register to index into your opcode tables)

3) leaving too few registers to hold all the emulated registers (oops, we only got r1..r3 in the left over registers; what about r4..r32...)

4) having to use "weak" or wrongly-specialized registers to hold the key RISC registers which are heavily used in the actual RISC program. (E.g., your program is trying to number crunch so it wants to do a lot of floating-point math on data which is being stored in some left-over CISC register which doesn't support floating point natively.)

[note, I'm well aware that x86 is not a CISC hardware implementation under the hood, but to the assembly programmer, it presents a CISC instruction set architecture. Emulating the underlying microcode RISC engine, however, would likely need even more registers, causing the same problems, so you would tend to emulate the CISC model.]

Best way to run Windows apps

[CdBee]

... 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.

Re:Best way to run Windows apps

[bedouin]

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.

Unless you don't want another desktop cluttering your room or house, and the noise, heat, and power consumption associated with it. Or if you work away from home on a regular basis, and need to have access to both Windows and OS X on your laptop.

Literally months go by sometimes before I need to do anything with Windows. An emulator is much better suited for someone like me than another PC I'd rarely use.

Re:Digital Convergence

[Speare]

Now they should reciprocate and port (or allow importation) of OSX apps to Linux.

And this helps them sell Apple hardware, how, exactly?

Re:Digital Convergence

[grunt107]

Well, it would help them sell iPods to me, since I have no Mac and refuse to use Windows.

Re:What about the "INE" part?

[dossen]

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).

A mature Darwine will be far from useless

[notNeilCasey]

The idea for as I understand it is this:

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 ... overhead city), Darwine allows applications to run essentially linked to native code - Wine/WineLib for PPC.

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.

Please stick to drivers at first

[kanweg]

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

Yum

[lukewarmfusion]

Did that say Port Wine?

Maybe I need to cut back on the Monday morning drinking.

Re:Too bad it's not the other way 'round

[Coming soon!]

It is... it's called PearPC. I set up OSX this weekend on an AMD64 3200+. It's PearPC is emulating a 1ghz G4 and I must say it's pretty sweet.

Re:Digital Convergence

[blackmonday]

EphPod.

There, now you can have an iPod too.

Re:Cloning Cocoa?

[dynamo]

Dude, google for OpenStep and GNUStep. Your wish has been granted. That'll be five bucks.

Re:Huh?

[bgarcia]

Do you realize that in less time than it took for you to write your questions, you could have clicked the link...

Welcome to slashdot! Enjoy your stay.

I'd rather have winelib ported to the mac

[Rob Y.]

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?