Darwine! WINE for Mac OS X is coming

135

Comments

  • Reply 41 of 90
    Do you remember in 1994 when the first 68k emulator appeared in MacOS 7. At that time it was really slow. And then a new version of the emulator bring a huge improvement to the speed of the emulation.



    In the interim, an article in MacTech (September 1994 Volume 10No9) explains how the Apple emulator works and offer some way to improve the first version. I was wondering if it was not possible to build on this principle to create a new and faster x86 emulator in PPC assembly language (and not in C like Bochs)...



    I think it could be interesting... This combine with the native speed of the Win32 Lib could bring a new level of emulation...



    Of course, there will always be the problem that WINE bring not the full Win32 library but a subset of them...
  • Reply 42 of 90
    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.
  • Reply 43 of 90
    Quote:

    Originally posted by mmmpie





    WINE translates windows api calls to linux api calls. This can still be done natively.




    Wouldn't the point of DarWINE (being separate from WINE) be to convert the windows api calls to darwin api calls instead? (which are then converted again by bochs, of course)



    Haven't read the story, so i might very well be wrong, but it would kind of makes sense. Otherwise one might just as well use standard WINE.
  • Reply 44 of 90
    bartobarto Posts: 2,246member
    Quote:

    Originally posted by LowB-ing

    Wouldn't the point of DarWINE (being separate from WINE) be to convert the windows api calls to darwin api calls instead? (which are then converted again by bochs, of course)



    Haven't read the story, so i might very well be wrong, but it would kind of makes sense. Otherwise one might just as well use standard WINE.




    WINE simply translates the calls, and rewriting it to use the Darwin/Mach calls would be hard work, when Mac OS X supports most Linux calls anyway (and many calls are the same across Linux/BSD/Darwin).



    Better to get a working product out now, then improve the speed of BOCHS, rather than do some not totally necessary rewriting of WINE.



    Barto
  • Reply 45 of 90
    hasapihasapi Posts: 290member
    Why Bochs?, its VERY SLOW!



    Check this out - x86 emulator



    Unless bochs has dramatically improved their code since July 03, qemu or valgrind would be preferred?



    Still this is a VERY interesting project, its certainly has my attention.
  • Reply 46 of 90
    Quote:

    Originally posted by hasapi



    Still this is a VERY interesting project, its certainly has my attention. [/B]



    Thanks to me! ^_^
  • Reply 47 of 90
    There is only one obvious, though not good enough, advantage to using Bochs. It's already ported. qemu does look an order of magnitude better than Bochs, and from the looks of their website, though not entire obvious or clear, it will run on PPC.



    I was browsing the Mailing List Archives for "mac os x". In the first message I read (Oct 06 03), someone said they had some things comiling, and something about ELF binaries. The next message (Oct 27 03) notes that Panther now emulates the calls. If you search a little more in the list, you'll find that it now mostly compiles (from relatively old messages and pages). I wonder why they don't use this instead, since if it's not done, it's really close. Is it a license issue?
  • Reply 48 of 90
    bartobarto Posts: 2,246member
    Quote:

    Originally posted by hasapi

    Unless bochs has dramatically improved their code since July 03, qemu or valgrind would be preferred?



    qemu certainly looks VERY interesting, more like VPC speed than BOCHS speed.



    I checked Valgrind's web page, and it "finds memory-management problems by checking all reads and writes of memory are checked, and intercepting all calls to malloc/new/free/delete."



    Looks like Valgrind isn't an emulator as such but can be used for development work in the same way an emulator can, so it's not relevant to Darwine.



    Barto
  • Reply 49 of 90
    hasapihasapi Posts: 290member
    Quote:

    Originally posted by Proud iBook Owner 2k2

    Thanks to me! ^_^



    I read this at http://www.macwindows.com/ first, sorry! With the WINE effort and qemu, the Darwine group "simply" make the two efforts work together.



    Now this is something I hope Apple would advance some of its talent to make the x86 emulator 'optimised for the G5'.



    I would guess this would be very strategic for Apple, which Apple 'for obvious reasons' may be supporting this effort covertly and for the same reasons the Linux community supprts WINE Why?



    Just my 2 cents



    Edit: FIXED! \
  • Reply 50 of 90
    hasapihasapi Posts: 290member
    Quote:

    Originally posted by Proud iBook Owner 2k2

    When linking to a site don't put a double http://. The link you posted about why WINE is needed looks like this when clicked: http://http://www.winehq.org/site/why. One HTTP'll do. ^^



    I apologise!, didnt paste the link in properly!, agreed its damm annoying for non functioning link!.
  • Reply 51 of 90
    mr. memr. me Posts: 3,221member
    Quote:

    Originally posted by FrenchMac

    Do you remember in 1994 when the first 68k emulator appeared in MacOS 7. At that time it was really slow. And then a new version of the emulator bring a huge improvement to the speed of the emulation.



    In the interim, an article in MacTech (September 1994 Volume 10No9) explains how the Apple emulator works and offer some way to improve the first version. I was wondering if it was not possible to build on this principle to create a new and faster x86 emulator in PPC assembly language (and not in C like Bochs)...



    I think it could be interesting... This combine with the native speed of the Win32 Lib could bring a new level of emulation...



    Of course, there will always be the problem that WINE bring not the full Win32 library but a subset of them...




    The original release of the PPC version of MacOS 7.1.x ran a very large portion of its code through the 68k emulator because the OS still contained large portions of 68k code. The major reason that subsequent versions of the emulator grew faster is that it had less to do. Another reason is that Apple made major improvements to ToolBox ROM functions. There has been very little improvement in the 68k emulator itself.



    It may be a nice fantasy that a magic emulator will substantially increase the execution speed of x86 code on the Mac. However, it will not happen.
  • Reply 52 of 90
    qemu seems to do what the second version of the 68k emulator of MacOS does back in old days: dynamic translation. The foreign code is translated into native code and then keep in memory. It's that new translated chunk of code which is natively run on the processor. This way a code must be convert only when even if it's executed several times.



    In the case of MacOS, the fact that strategic APIs have been ported to PPC over time have also increase the overall speed of the emulation process (like a complementary use of WINE can do on a x86 emulator) but the core of the emulation engine also improved at this time (System 7.5).



    That would be great if some talented Apple developer could work on a project like qemu to bring it to maturity more quikly.



    In the past years X11 has been successfully integrated to the MacOS X to ease the port of Unix application. It would be cool to see another step like this with x86/WIN32 application compatibility... It recalls me the rumored "Red Box" project.
  • Reply 53 of 90
    bartobarto Posts: 2,246member
    Quote:

    Originally posted by FrenchMac

    The foreign code is translated into native code and then keep in memory. It's that new translated chunk of code which is natively run on the processor.



    This is how VirtualPC's recompilation engine works, which would be a big reason why qemu appears to be about the same speed as VPC.



    Darwine is intended to run Windows applications as Mac OS X applications, or at the least X11 applications (which with Apple's utterly fantastic X11 window server and manager feature graphics acceleration - a huge plus).



    If they actually get everything working, and it doesn't end up being dog slow, Darwine would probably not replace VirtualPC.



    Darwine might be a real option for everyday users wanting to "protect their investment" in Windows applications... unlike VirtualPC you don't actually run Windows and the applications appear like native (or at least native X11) applications, so it is infinitely more attractive for more regular home use.



    However, that is also a downside in that WINE is less compatible than actually running Windows inside a Virtual Machine, and so VirtualPC would remain the product of choice for obscure business and hardware support applications that are Windows only.



    Barto
  • Reply 54 of 90
    They've released a binary!!!! Check it out at http://www.sf.net/projects/darwine !!!!
  • Reply 55 of 90
    OK so I installed it... but now I can't get it running... I'll install X11 but I don't think that'll help because it's looking for the Windows drive... I don't know where the config file is to set that and I can't find a WineTools that'll work... Can anyone help? Would I need the previous version? CONFIRMED: the Darwine team IS NOT using Bochs. They're, indeed using Qemu like many of you mentioned here...



    Here's what happens (in terminal.app) when I try and start wine:



    Last login: Thu Jan 29 16:14:36 on ttyp2

    Welcome to Darwin!

    [Gaspar-Hellers-Computer:~] gasparhe% wine

    dlopening /usr/local/lib/wine/ntdll.dll.so

    done /usr/local/lib/wine/ntdll.dll.so

    dlopening /usr/local/lib/wine/kernel32.dll.so

    done /usr/local/lib/wine/kernel32.dll.so

    Warning: no valid DOS drive found, check your configuration file.

    Warning: could not find wine config [Drive x] entry for current working directory /Users/gasparhe; starting in windows directory.

    Invalid path L"c\\\windows" for L"windows" directory: does not exist.

    Perhaps you have not properly edited your Wine configuration file (/Users/gasparhe/.wine/config)



    Oddly enough after I installed X11 just now X11's Xterm says it can't find wine when I type it:



    Gaspar-Hellers-Computer:~ gasparhe$ wine

    bash: wine: command not found

    Gaspar-Hellers-Computer:~ gasparhe$



    How do I get this to run under X11.app? I know once I get it started that it'll need some sort of Windowing environment and display method...



    I've rehashed several times... Can anyone help?
  • Reply 56 of 90
    pbpb Posts: 4,234member
    Quote:

    Originally posted by Barto

    Darwine might be a real option for everyday users wanting to "protect their investment" in Windows applications... unlike VirtualPC you don't actually run Windows and the applications appear like native (or at least native X11) applications, so it is infinitely more attractive for more regular home use.



    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?
  • Reply 57 of 90
    jidojido Posts: 109member
    Quote:

    Originally posted by Proud iBook Owner 2k2

    OK so I installed it... but now I can't get it running... I'll install X11 but I don't think that'll help because it's looking for the Windows drive... I don't know where the config file is to set that and I can't find a WineTools that'll work... Can anyone help? Would I need the previous version? CONFIRMED: the Darwine team IS NOT using Bochs. They're, indeed using Qemu like many of you mentioned here...





    Yes, I saw that in the FAQ page: they went with QEMU instead of Bochs.



    If I understand well, Darwine means that I can recompile an application using (a subset of) the Win32 API to run under MacOS X/X11? This is awesome!



    I wonder if Darwine is PPC-native, that is that it doesn't use the QEMU emulator itself? It would make sense. The x86-specific code in the application would be handled by QEMU, and the remaining would run at native speed.

    How much of a PC program is stuff that is already implemented in the Wine library? How much of it needs QEMU to run on a Mac?



    Imagine in the future, installing X11 would install Darwine as well, giving instant access to a range of (fast!) Windows applications!
  • Reply 58 of 90
    There is a shell script that sets it up someplace but I cannot remember where right now.
  • Reply 59 of 90
    Quote:

    Originally posted by jido

    Yes, I saw that in the FAQ page: they went with QEMU instead of Bochs.



    If I understand well, Darwine means that I can recompile an application using (a subset of) the Win32 API to run under MacOS X/X11? This is awesome!



    I wonder if Darwine is PPC-native, that is that it doesn't use the QEMU emulator itself? It would make sense. The x86-specific code in the application would be handled by QEMU, and the remaining would run at native speed.

    How much of a PC program is stuff that is already implemented in the Wine library? How much of it needs QEMU to run on a Mac?



    Imagine in the future, installing X11 would install Darwine as well, giving instant access to a range of (fast!) Windows applications!




    I have no clue but I just wrote to the developer asking him how to get it working. On the Darwine Project home page (http://darwine.sf.net) they have a screenshot posted there. I really want to know how to get that far. As it is now the program that runs it doesn't find it and the one that finds it doesn't run it. In other words Terminal.app almost loads up, and X11.app doesn't find the command at all...
  • Reply 60 of 90
    In x11 make sure you CD to the directory and put a ./ in front of wine
Sign In or Register to comment.