Darwine! WINE for Mac OS X is coming

124

Comments

  • Reply 61 of 90
    Quote:

    Originally posted by SilentEchoes

    In x11 make sure you CD to the directory and put a ./ in front of wine



    Didn't work... but I'll wait for either Jim White (the project admin) or SE to find the shell script.
  • Reply 62 of 90
    hasapihasapi Posts: 290member
    Quote:

    Originally posted by Proud iBook Owner 2k2

    CONFIRMED: the Darwine team IS NOT using Bochs. They're, indeed using Qemu like many of you mentioned here...



    Wow!, they must have just updated their site. Im curious?, I hope they didnt JUST discover QEMU!, sorry, Im rarely cynical. That said, QEMU is using some of Bochs bios.



    One test might be to see how fast QEMU runs under x86 - its suppose to be about 4 times slower (integer) and 10 times (floating point) - translated to some real world experiences?.



    Add WINE for x86, and this might give some indication on the type of performance we could expect?.
  • Reply 63 of 90
    bartobarto Posts: 2,246member
    Quote:

    Originally posted by PB

    If you are running VPC, a Windows virus can ruin your VPC disk image like a real PC, but nothing outside this one. Now, does what you are saying about Darwine means that a Windows virus can damage the OS X installation?



    From the look of the following article



    http://www.vnunet.com/News/1125594



    WINE is not very susceptible to virii, but it CAN happen. Rarely. Unlike VirtualPC, which is just as suceptible to Windows.



    Barto
  • Reply 64 of 90
    hmmm that sucks... I guess we gotta be careful then. heh



    OT: My stupid mail provider died so I gotta use another email address which is why I'm posting..to get this other addy into the system......
  • Reply 65 of 90
    akacakac Posts: 512member
    Quote:

    Originally posted by Proud iBook Owner 2k2

    Since at the moment Darwine can only really be useful if you compile your own Win32 apps from source, has anyone been successful with that? Though it's in the works as a native OS X app, I'd like to see DC++ running under Darwine. That would be cool. If anyone wants to try compiling DC++ you can DL the source here: http://dcplusplus.sf.net.



    I'm thinking about it. As a Pocket PC developer we do have source for our own windows apps. I've been wanting WINE for OS X since we moved back to the Mac. I don't care about emulation...just WINE so I can recompile against it. When I have time I guess....
  • Reply 66 of 90
    Doesn't the emulator need to run an operating system? It seems like Wine on a PC doesn't just run on x86 hardware, it instead runs within an Operating System which is running on x86 hardware. So it would seem that Darwine would need to run on an emulated x86 OS. If that is the case, which OS are thy emulating? It would be interesting if it ran on a port of Darwin x86. If an OS doesn't need to be emulated, please explain plainly why it doesn't.



    Alexander the Great
  • Reply 67 of 90
    Quote:

    Originally posted by Alexander the Great

    Doesn't the emulator need to run an operating system? It seems like Wine on a PC doesn't just run on x86 hardware, it instead runs within an Operating System which is running on x86 hardware. So it would seem that Darwine would need to run on an emulated x86 OS. If that is the case, which OS are thy emulating? It would be interesting if it ran on a port of Darwin x86. If an OS doesn't need to be emulated, please explain plainly why it doesn't.



    Alexander the Great




    -_- Can anyone straighten him out? I'l try but... *sighs*



    Alexander: WINE stands for WineIsNotanEmulator. It's a compatibility layer that allows Linux users to run Windows applications. Until now it was only available for people using x86 based hardware. The Darwine team is using an emulator, or as they call it a binary translator, to run the x86 binaries. It's called QEmu. This will allow Mac OS X and Darwin PPC users to run WIndows apps, without having an installation of Windows present. There is no "port of Darwin x86". Darwin is written for both the PowerPC processor as well as x86 processor. Darwine uses Apple's Xfree86 Window/X server called X11 to display these programs. For more information go back to the first post of this thread to visit the Darwine project home page. That's all I can say off the top of my head on this. Anyone else want to collaborate?
  • Reply 68 of 90
    Let me see if I've got this straight. I can see Darwine working in two different ways. It seems like you are describing the first way I'll now try to describe to see if I've got it straight.



    Method One: Darwine (a program that needs to be run inside an OS, just like any other program) will run in PPC Darwin, but it will translate many of it's instructions using an x86 emulator.



    Method Two: Darwine will run in Linux (or another OS) which is being run in an x86 emulator.



    Alexander the Great



    P.S. I understand how wine works when run on x86 hardware. I know that it doesn't need Windows to run programs. And yes there are x86 ports of Darwin. At least by how I define a port, a compiled binary for some particular hardware. There are Darwin binaries compiled for x86, which sure seems like a port to me. If my definition of a port is wrong than there's no disagreement. It's not a big deal any way, that's why it's in a "P.S."
  • Reply 69 of 90
    Or wait, even better, if Darwine could run Windows applications that are compiled for PPC natively and applications that are compiled for x86 would be run using the emulator/code translator. That way if something is compiled for PPC, then it would run real fast, but if it wasn't, it would still be able to be run.



    Alexander the Great
  • Reply 70 of 90
    VPC works by emulation an x86 processor. Doing so, you can run any x86 OS on top of it. For Windows applications, you run a version of Windows with all it?s system files and everything. A Windows application, works with the files describing the WIndows API. (This is what I gather from the Wine site.)



    Darwine = Wine + QEmu. QEmu emulates the x86 processor. In theory, you could run anything x86 on top of it, but that?s not the goal of this project. Wine, is used to translate (not emulate) system calls to their Linux equivalents (again what I gather from the Wine site). QEmu takes these instructions and converts it to PPC code for execution. Now, I assume for this project, that the middle conversion to Linux code will be eliminated. I?m goin to try to visualize this.

    Code:


    Windows Application

    ||||||||

    Windows API

    ||||||||

    WINE---------------------------Windows

    ||||||||

    QEmu---------------------------VPC Emu

    ||||||||

    PPC Code





    Initially, the Windowing would have to be done in an X11 environment. Though eventually, you might be able to put an Aqua face on it.



    With additional development of the Windows APIs available to Wine. Things will become much easier to run. Currently, I believe, you must build from sources for Wine. I?m not sure if the additions will eliminated that, but it will definently enhance the available options.



    ---

    Neither method is correct if I'm reading them correctly. Method 1 is close. I've made a few changes:



    Method One: Darwine (a program that needs to be run inside an OS, just like any other program) will run in PPC Darwin, but it will translate Windows instructions using using Wine, which are translated into PPC instructions with an x86 emulator.



    I think I have all this right. And to make the websites available easily on this page and from my post.

    Wine

    Darwine

    QEmu
  • Reply 71 of 90
    Quote:

    Originally posted by macserverX

    [B]VPC works by emulation an x86 processor. Doing so, you can run any x86 OS on top of it. For Windows applications, you run a version of Windows with all it?s system files and everything. A Windows application, works with the files describing the WIndows API. (This is what I gather from the Wine site.)



    Darwine = Wine + QEmu. QEmu emulates the x86 processor. In theory, .....



    Thank you for helping me MacserverX. I hope Alexander knows what Darwine is now...
  • Reply 72 of 90
    You're welcome. The Home page for WINE states in its first paragraph that you can use DLLs if they're available. I'm exactly sure what they are, but I assume that if you have some Windows files, things might work a little better. I guess.
  • Reply 73 of 90
    Has anyone gotten this to work yet? The binary I downloaded as well as the original source distribution aren't working for me in any capacity. Actually, none of the commands that I've tried to use to even get it to run have worked (X11 Terminal) and a search for anything involving the app on my hard drive only turns up the package and the package receipt.
  • Reply 74 of 90
    Quote:

    Originally posted by macserverX

    Has anyone gotten this to work yet? The binary I downloaded as well as the original source distribution aren't working for me in any capacity. Actually, none of the commands that I've tried to use to even get it to run have worked (X11 Terminal) and a search for anything involving the app on my hard drive only turns up the package and the package receipt.



    Same here. It's annoying but I guess that's what you have to deal with when messing with Alpha software.... I hope they improve it soon. What we need to get it going properly is something like WINETools.. but I think their planned System Prefs Pref pane is gonna act as that. What's odd for me is that when I type wine into Terminal.app it sorta works but then it asks for the fake C drive...... then again in X11.app it doesnt work at all... WTF....
  • Reply 75 of 90
    hasapihasapi Posts: 290member
    Speaking from an Integration perspective, this project would have to rate as one of the most important open source projects going around!.



    I hope developers get behind this! (are you listening Apple!).



    I could sell a ton MORE Apple boxes if those 'pesky' few windows apps would work without running windows OS.



    Darwine on a G5 15" iMac - for the businesses is my humble request!
  • Reply 76 of 90
    Quote:

    Originally posted by hasapi

    I hope developers get behind this! (are you listening Apple!).



    I could sell a ton MORE Apple boxes if those 'pesky' few windows apps would work without running windows OS.



    Darwine on a G5 15" iMac - for the businesses is my humble request!




    I earnestly hope that Apple never endorses such a project and never includes it with its computers.



    Such a move would say to developers, "Why bother writing a native version of your titles when the Windows version will run fine?"



    Unwise.



    Like VirtualPC, this would be fine for third-parties to work on and ship. That'll mean the majority of users probably still won't have it.



    You may think this is good from your perspective. In fact, it may be good in the present. Look at it from the developers' perspective, though. The same issue existed with Classic, even. I cite the length of time it took for Quark to get XPress running natively on Mac OS X. Developers won't port for fun; they'll need a damn good reason to do it. If an existing version will work, why bother rewriting a lot of it from the ground-up for Macs?
  • Reply 77 of 90
    hasapihasapi Posts: 290member
    Quote:

    Originally posted by Brad

    I earnestly hope that Apple never endorses such a project and never includes it with its computers.



    The reason why alot of firms reject the Mac platform, is because there is almost ALWAYS a few industry specific apps that are required for day to day business. The majority of computing requirements are taken care of the Mac. As a result Apple misses out on alot of potential business, even Linux recognises this here



    This is why, IMO, this is SO important. I understand that Apple promotes developers of native OSX code, and I NEVER stated that Apple would include this as a integrated OS capability, that could be political suicide and like you said, may send the wrong message to developers.



    The reality is such that there are literally hundreds of windows apps that will NEVER be ported to the Mac, because 1. it most likekly cost prohibitive to do so. 2. Whats the point if the market share for Mac is 3%?, and 3. They likely to be too industry specialised.



    Lastly, your absolutely right in an ideal world, but unfortunately this is reality and MS has 90%+ of the computing mindshare!, Sorry \
  • Reply 78 of 90
    Odd.. The Darwine Team released an uninstaller and when I try and run it in Terminal.app it keeps saying command not found.. But it's a text file (a Perl script I think) and you can see what it would do for you if it was run. Can anyone get it to work? And why do you think they've released an uninstaller? Could they be readying the first real release with QEmu built in?
  • Reply 79 of 90
    I don't see Darwine working exactly like it's described above. As I understood it from a developer point of view, WINE (and so Darwine) is a set of libraries that match the WIN32 libraries. When they run on Linux x86, they allow a WIN32 application to work on Linux without the need of Windows.



    From what is described on the Darwine site, the WINE Lib has been ported to native PPC code on MacOS X. So a WIN32 application for which the source code is available (or the developper of an application) can choose to compile it under Darwine to make it avaible to the MacOS X community.



    As such it is already really interesting to accelerate the port of a particular form of applications to MacOS X: games. But it will be really interesting for this purpose when the Darwine project will have a Direct3D support (on top of OpenGL).



    The next step in that project is to include the x86 binary translator Qemu in Darwine so that x86 WIN32 applications could be run without modifications. That could achieve a high level of performance because all the time the application time passed in the WIN32 APIs will be running native code. The only x86 code that will remain will be the code of the application itself. This operating mode will be closed to the one of the MacOS 68k emulator.



    As it is described on the WINE web site, this is a huge work due to the fact that the binary memory format of the data manipulated by WINE on PPC is not the same as the format provided by the x86 part of the application (due to litte endian/big endian and memory alignment). So the Darwine project must include the necessary convertions here (which will be costly in term of execution time). It's really a huge work due to the complexity of the WIN32 APIs (which contain a lot of structures).



    So even if today the WINELib is available on MacOS X, there is still a long road to a full WIN32 application compatibility. But it's definitely a step in the right direction.



    And no, I don't think that it will be a bad think for Apple on the long term because an application running into WINE will never be as good as a native MacOS X application. It will only do what's does the X11 layer in MacOS X: open the operating system to more users. I don't think that the big names in software development (Adobe, Macromedia, etc...) will use Darwine to reduce the cost of dev of their applications. And there is already very little WIN32 app that are ported to MacOS X... It could only encourage a wider used of our platform by removing a part of the software incompatibility image it has among PC users (on the long run of course).
  • Reply 80 of 90
    costiquecostique Posts: 1,084member
    VPC has one huge advantage over Darwine: compatibility. 999 of 1000 Windows apps can't even figure out they are running on a PowerPC. Moreover, I myself installed FreeBSD and Linux RedHat for x86 on VPC. Both worked great. With VPC you get a fully functional x86 box, which is downright cool.



    On the other hand, this is also a huge disadvantage, because you have to run a whole operating system to run a miserable solitaire. The problem is not Windows itself, or Microsoft, or anything: any operating system eats hardware resources needed to run the simplest of applications. With VPC we actually have MacOS with 2 or 3 dozens of background processes and its hardware abstraction layer, on top of which another OS (be it Windows, Linux or BeOS) is being slowly emulated through another HAL, on top of which the poor little app believes it's running.

    Since Darwine is not an OS, it does not bog down its own hardware emulation by running unnecessary tasks, like VPC has to. Remember SoftWindows? So, I guess, Darwine potentially can run software faster than VPC at the expense of compatibility.



    There is one more problem with Darwine approach: the same DLLs used in different Windows versions are obviously different, so Darwine can effectively emulate one version of Windows at a time.
Sign In or Register to comment.