Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
OS X Operating Systems Software Wine

Interview - Jim White of the Darwine project 233

Posted by Hemos from the bettering-the-platform dept.
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."
This discussion has been archived. No new comments can be posted.

Interview - Jim White of the Darwine project More

Interview - Jim White of the Darwine project

Comments Filter:

  • Confused.... (Score:5, Interesting)

    by Vengie ( 533896 ) on Monday August 23, 2004 @11:27AM (#10045194)
    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...."
    • WINE = Wine Is Not an Emulator = Windows Emulator

    • Re:Confused.... (Score:5, Informative)

      by Vengie ( 533896 ) on Monday August 23, 2004 @11:48AM (#10045522)
      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.... (Score:3, Insightful)

      by burns210 ( 572621 )
      It will be running QEMU, an emulator, that will be closely tied to Winelib, which will then run Windows executables.

    • Re:Confused.... (Score:5, Insightful)

      by ArsonSmith ( 13997 ) on Monday August 23, 2004 @04:01PM (#10048865) Journal
      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! (Score:5, Interesting)

    by El_Ge_Ex ( 218107 ) on Monday August 23, 2004 @11:29AM (#10045234) Journal
    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

    • Trouble is... (Score:5, Insightful)

      by Kjella ( 173770 ) on Monday August 23, 2004 @11:39AM (#10045386) Homepage
      ...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... (Score:5, Insightful)

        by BasilBrush ( 643681 ) on Monday August 23, 2004 @12:38PM (#10046219)
        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.

      • MOL (Score:3, Informative)

        by WiseWeasel ( 92224 )
        LinuxPPC users can already use MacOnLinux to run MacOS X and all its apps natively in the Linux environment, with almost perfect compatibility.
      • The problem is emulating a PPC processor on x86 hardware. It is much harder than the other way around.

        Why is this? I've never heard this. I would have thought the PPC instruction set to be simpler than x86.

        • Re:Trouble is... (Score:5, Informative)

          by jaoswald ( 63789 ) on Monday August 23, 2004 @03:15PM (#10048144) Homepage
          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.]
    • Sure; take GNUstep, finish it up and slap QEMU and a MacOS X binary loader on top of it :)

      (I'm half-serious, by the way. GNUstep does implement a lot of the necessary APIs.)

    • Re:I got a better idea! (Score:5, Insightful)

      by TheRaven64 ( 641858 ) on Monday August 23, 2004 @11:47AM (#10045501) Journal
      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! (Score:5, Informative)

      by dmayle ( 200765 ) * on Monday August 23, 2004 @11:50AM (#10045554) Homepage Journal

      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 [maconlinux.org]. 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 [sourceforge.net]. And you know what? They're both open source...

    • Re:I got a better idea! (Score:3, Insightful)

      by mystik ( 38627 )
      Try Mac On Linux [maconlinux.org] (Like vmware for PPC, PPCLinux only obviously)

      Or try Sheep Shaver [uni-mainz.de], a portable PPC emulator, although they admit to not being able to run OS X yet. (And you still need a PPC ROM image)
    • It's called "bitch the developers to port to GNUstep." :)

    • Re:I got a better idea! (Score:5, Informative)

      by RAMMS+EIN ( 578166 ) on Monday August 23, 2004 @12:08PM (#10045787) Homepage Journal
      NetBSD [netbsd.org] is working on Darwin binary compatibility [hcpnet.free.fr]. Something similar could be attempted by Linux.

    • Re:I got a better idea! (Score:5, Informative)

      by mrchaotica ( 681592 ) on Monday August 23, 2004 @12:58PM (#10046456)
      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 (Score:5, Informative)

    by Alex Reynolds ( 102024 ) on Monday August 23, 2004 @11:30AM (#10045244) Homepage
    Apps are not running natively:

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

    • Re:Read the site (Score:3, Insightful)

      by gl4ss ( 559668 )
      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..

      • bzz was wrong.. (Score:3, Informative)

        by gl4ss ( 559668 )
        "The second phase is to then integrate in WINE the QEMU binary translator."

        that comes later then.
      • 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.
    • ... Microsoft will freely provide us with their source code so we can compile Office and their other product suites on MacOS.

    • bad moderation (Score:2, Informative)

      by hobo2k ( 626482 )
      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.

  • Sign me up! (Score:3, Interesting)

    by keiferb ( 267153 ) on Monday August 23, 2004 @11:30AM (#10045256) Homepage
    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.

    --

  • Clarification (Score:5, Insightful)

    by torstenvl ( 769732 ) on Monday August 23, 2004 @11:31AM (#10045268)
    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 [opendarwin.org]

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

  • The emulator part is... (Score:4, Informative)

    by pedestrian crossing ( 802349 ) on Monday August 23, 2004 @11:31AM (#10045277) Homepage Journal
    QEMU...

  • Is there really a need? (Score:5, Interesting)

    by HogGeek ( 456673 ) on Monday August 23, 2004 @11:32AM (#10045289)
    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? (Score:5, Funny)

      by LiquidCoooled ( 634315 ) on Monday August 23, 2004 @11:48AM (#10045518) Homepage Journal
      Gator, Mydoom, Welchia, CWS, Sobig, Nimda.

      Did I miss any out ;)
    • MS Access is a deal breaker for many who would be willing to run Office on a Mac.

      Sure, there's MySQL etc, but if you have to have Access, you have to have Windows.

      • Re:Is there really a need? (Score:5, Interesting)

        by molarmass192 ( 608071 ) on Monday August 23, 2004 @12:15PM (#10045889) Homepage Journal
        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.
    • I use Wine to run the Logos Library System - a Windows-only e-book program with a proprietary file format which prevents me writing a clone. The reason - I've got over one hundred pounds' worth of books for it, bought when I used Windows.

    • Re:Is there really a need? (Score:3, Insightful)

      by 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?
    • Solidworks and AutoCad come to mind.
      Or any of the thousands of PC only programs out there that people need to do there jobs. Many vertical market programs only run on the PC if it became easy to write for the Mac and PC using Winelib you could see some apps become available for both platforms
      • 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 engineeri

    • Re:Is there really a need? (Score:5, Insightful)

      by burns210 ( 572621 ) <maburns@gmail.com> on Monday August 23, 2004 @01:20PM (#10046708) Homepage Journal
      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? (Score:4, Informative)

      by ArsonSmith ( 13997 ) on Monday August 23, 2004 @04:14PM (#10049057) Journal
      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 (Score:4, Interesting)

    by Ars-Fartsica ( 166957 ) on Monday August 23, 2004 @11:32AM (#10045293)
    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 (Score:5, Insightful)

      by agby ( 303294 ) on Monday August 23, 2004 @11:49AM (#10045535)

      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 [apple.com]

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

  • Wonderful... (Score:4, Funny)

    by transient ( 232842 ) on Monday August 23, 2004 @11:33AM (#10045306)
    Just what I needed, a way to run crappy Windows apps on OS X!

  • Wine is a godsend....but..... (Score:5, Interesting)

    by Savet Hegar ( 791567 ) on Monday August 23, 2004 @11:34AM (#10045313)
    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.
    • with this you wouldn't only need to be able to install some software.. you would need to recompile the whole shisbang.
      • after digging little further..

        in "second phase" with the darwine integrated to qemu you would be able to run native x86 windows apps.. or something.

        just get the damn vpc or run them in full qemu'ed windows environment now..

    • that crossover has managed to overcome. When will the code be incorporated back into Wine?

      Sorry to break your preconceptions, but for sometime now Crossover has been very diligent in submitting their improvements upstream into WINE. Photoshop compatibility should already be checked in...

    • Yeah, sure, the bottleneck of the whole project may be Wine itself. I think that's what the guy said in the interview: several years before DarWINE works right, but maybe only one year before it runs apps as well as WINE on Linux. If this is so, there will be many very excited mac fans in about a year, because WINE works pretty well now, and in a year it will be even better. If DarWINE can smooth out the PPC backend for WINE by then, many people will find the result useful.

      The point is that the structure

    • ie6 runs fine with crossover office. same with photoshop and quicktime, and some other big name applications.
    • It fails to run a lot of popular software right out of the box. Last I checked, it wouldn't install IE6.

      Hell, I couldn't even get it to run Minesweeper! I copied over winmine.exe and I get:

      fixme:ntdll:NtQueryVolumeInformationFile device info not properly supported on this platform
      wine: cannot determine executable type for L"Z:\\       (...path...) \\wimine.exe"

      Is there something more I need to do?

  • Best way to run Windows apps (Score:5, Informative)

    by CdBee ( 742846 ) on Monday August 23, 2004 @11:56AM (#10045648)
    ... 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 (Score:4, Informative)

      by bedouin ( 248624 ) on Monday August 23, 2004 @12:36PM (#10046196)
      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.
  • I'd much rather run OSX on Windows than Windows on OSX.

    Anybody doing this kind of thing?

  • Please stick to drivers at first (Score:3, Interesting)

    by kanweg ( 771128 ) on Monday August 23, 2004 @12:30PM (#10046119)
    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 (Score:5, Funny)

    by lukewarmfusion ( 726141 ) on Monday August 23, 2004 @12:35PM (#10046183) Homepage Journal
    Did that say Port Wine?

    Maybe I need to cut back on the Monday morning drinking.
  • I am not a developer, so I'm interested to know if this idea is possible. Darwine will use a custom library for Win32 applications. How much power does that afford developers to change the way the libraries work? Could an OS X version of the Darwine libraries "intercept" the calls from the .exe and, for example, display the app's menu options in the menu bar instead of in the application window? How about replacing boring gray buttons in dialog windows with aquafied buttons? How about scroll bars?

    If this i
    • 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.)
  • 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?
    • QEMU works just fine on the G5. VPC made some optimizations by using native x86 endian compatability which does not carry to the G5. I do not believe QEMU has these optimizations, which can be seen as a good thing or a bad thing. :)

  • I'd rather have winelib ported to the mac (Score:3, Insightful)

    by Rob Y. ( 110975 ) on Monday August 23, 2004 @02:06PM (#10047301)
    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?

  • cathedral vs Bizarre (Score:3, Funny)

    by wembley ( 81899 ) on Monday August 23, 2004 @04:36PM (#10049355) Homepage
    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.

  • But what about security ? (Score:3, Funny)

    by ultranova ( 717540 ) on Monday August 23, 2004 @05:31PM (#10050069)

    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.

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

  • Doesn't work (Score:3, Informative)

    by Zareste ( 761710 ) on Monday August 23, 2004 @07:40PM (#10051284) Homepage
    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.

Slashdot Top Deals

Without life, Biology itself would be impossible.

Close