Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


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

WINE for Mac OS X in Development 150

Posted by pudge from the but-can-i-play-games-on-it dept.
TylerL82 writes "The Darwine Project aims to get WINE up and running through X11 on Mac OS X/Darwin. According to the site, WINE itself compiles rather well, and they'll be using Bochs for the actual x86 emulation. Quite an interesting idea. It's crazy, but it just might work!"
This discussion has been archived. No new comments can be posted.

WINE for Mac OS X in Development More

WINE for Mac OS X in Development

Comments Filter:

  • wwwwoooorrrrrkkkkk (Score:4, Insightful)

    by soboroff ( 91667 ) on Thursday January 29, 2004 @02:19PM (#8126348)

    It just might work... but veeeeeeery slowly, if Bochs is underneath it.

    • Re:wwwwoooorrrrrkkkkk (Score:5, Insightful)

      by forsetti ( 158019 ) on Thursday January 29, 2004 @02:22PM (#8126388)
      Actually, this might work out OK -- from their site, Bochs is going to be stripped down (no interface, no SDL, etc) and /just/ provide x86 emulation -- sort of like a software processor. Yes, it will not provide native speed, but it might just be "good enough"....

      • Re:wwwwoooorrrrrkkkkk (Score:4, Informative)

        by addaon ( 41825 ) <addaon+slashdot@nOsPAM.gmail.com> on Thursday January 29, 2004 @04:02PM (#8127628)
        Unfortunately, the slow part of Bochs is not the front end, it's the emulator. Admittedly, calls to the WINE api will run at native speed, but I imagine that very few windows programs spend most of their time there. Otherwise, expect slowdown of 99% - 99.9%... my G3/600MHz runs console apps in Bochs at around 900kHz equivalent.

        • Re:wwwwoooorrrrrkkkkk (Score:4, Insightful)

          by Cecil ( 37810 ) on Thursday January 29, 2004 @08:21PM (#8130294) Homepage
          On the contrary. I'd suggest that *most* windows programs spend most of there time there. In particular, GDI drawing is one of the slowest things you can possibly do in the windows API -- and almost every application does it, to some extent. Which is not to say that Microsoft's GDI sucks (it does) but graphics are a notoriously slow operation when you're busy calculating margins and colors and transparencies and fonts.

          By the way, I hope your numbers are exagguration. If Bochs on a 600MHz processor is incapable of running a program faster than an 8088, then I will be somewhat disappointed.
          • My numbers are not, unfortunately, exaggeration (how the heck do you spell that, anyway?). They are, however, based on a straight compile with no check of optimization or anything. And I assume it would be measurably less bad on a machine that didn't need to do as much byte swizzling.
        • Back in my emulator days (Virtual PC 1.0-2.0 era), there were a number of lively discussions in IRC and on a couple of emu-lists on why Bochs would never be as fast as something like Virtual PC.

          Basically, it's because Bochs is written for platform compatibility, not for speed. Because of that, hardware reordering optimizations and true dynamic recompilation are not possible. Bochs also couldn't be fully register and cache optimized or use some of the PPC hardware tricks such as byte swapping using the PC
    • For my money, I'd rather just buy a used PC and run Windows on it. Just last month I went shopping for a used video card for my boy's PC so it would run a game he got for Christmas, and they had used midi-tower PCs with power supply, motherboard, and a 400MHz Celeron for $20. $20! Add memory, a moderate (20Gig) hard disk, video card, and keyboard and for around $100 you can have a fairly decent PC. It's used, and a bit of a Frankinstein, but it will run MS Office, and that's what most people want anyway.

      No,

      • Why would a Mac user want a PC for Microsoft Office when Microsoft already produce a version of Office that is significantly superior to the Windows version that runs natively on Mac OS X?
        • That's sort of my point. Other than games, what Windows software are you going to run on your Mac that isn't available in a native Mac version? And if you want to play games, you're going to be dissapointed with an emulator. If there's some Windows app you really, really, need I think it will run faster on a $100 used PC than on this emulator within an emulator approach.
          • Well, I use VPC to access the windows-only management program for my AP (it was cheap, and I had a pc then...). Also, as other have mentioned, there are loads of in-house programs that (unfortunately) are written for Windows only. Then there's the whole Exchange-MAPI thing that still is only fully implemented in Outlook for WIndows. Not to mention CRM software...that's a whole other platform lock-in story. True, the home user will probably not want for software selection...but the business/enterprise us
      • congrats you lucked out (btw where was this?).

        Normally just that case would be $60, that barebones bundle would normally be around $200 if it was decent hardware, and $120 if it was crap. But we'll go with $20 for that.

        Memory $70
        20gig drive $40
        video card $40-$150
        keyboard $20
        mouse $20

        Going with bottom of the line video card (this entire scheme makes for a web browsing box not a gaming box but hey) that's $210 including your mobo combo.

        $400 is what MOST people are going to be able to get that box for.

    • Comment removed (Score:5, Informative)

      by account_deleted ( 4530225 ) on Thursday January 29, 2004 @04:51PM (#8128209)
      Comment removed based on user account deletion
    • Take a look at their forums where this question was asked: qemu, not bochs [sourceforge.net]

  • This will be really slow (Score:5, Insightful)

    by NanoWit ( 668838 ) on Thursday January 29, 2004 @02:20PM (#8126367)
    The reason we haven't seen WINE off of x86 yet is because like the name says "Wine Is Not an Emulator". So there's no code in wine that simulates the processor/real hardware. Bochs was just pitifully slow the few times that I used it. This won't have any kind of speed

    • Re:This will be really slow (Score:5, Funny)

      by Joey Patterson ( 547891 ) on Thursday January 29, 2004 @02:42PM (#8126652)
      there's no code in wine that simulates the processor/real hardware

      True that, but what about other solutions [overclockers.com] for running PC software on your Power Mac G5?
      • Oh god, the humanity. I saw that for the first time this morning, and I just know I'm going to have nightmares about it tonight.
      • That is one of the worst things I've ever seen! It kinda puts Mr. Goatse to shame...
        I'm going to have nightmares for a really long time.
      • From my submitted items list:

        2004-01-28 19:23:31 Apple G5 converted into a PC (articles,apple) (rejected)

        Oh well, I tried.
      • Apparently this one has a speed problem... Not good enough for running a websever, at least ;-)

        ----------------
        HTTP Error 403

        403.9 Access Forbidden: Too many users are connected

        This error can be caused if the Web server is busy and cannot process your request due to heavy traffic. Please try to connect again later.

        Please contact the Web server's administrator if the problem persists.

      • Re:This will be really slow (Score:5, Funny)

        by Llywelyn ( 531070 ) on Thursday January 29, 2004 @06:19PM (#8129149) Homepage
        From the article:

        >I have to say that I'm happy - I can keep on using XP. ....and thus getting what he richly deserves for that crime against nature.
      • from what I understand even the worst outcome of this WINE project would probably run faster than the piece o' shit innards this kid gutted his G5 to install, especially since the brat was too dumb to realise he could have re-used the G5's gfx card...
    • Yes and that's why they're including Boch with it for the x86 emulation.

    • "Slow" is relative (Score:5, Interesting)

      by fm6 ( 162816 ) on Thursday January 29, 2004 @03:17PM (#8127100) Homepage Journal
      It's true that emulating a serious CPU takes a lot of crunching. Which is why we've traditionally relied on campatibility layers (like Wine) and hardware support. But like many other problems, this one is being nibbled at by increasing CPU specs.

      When I want to play an old DOS game on my XP system, I don't mess with a compatibility layer (complicated and unreliable) or reboot to DOS (damned inconvenient). I run DOSBox [sourceforge.net], which emulates not just the CPU, but the sound card and video adapter as well! The overhead is horrendous (Sword of the Samurai takes more than half the cycles on my 1 Ghz Pentium III), but well within the capacity of my system. And that's a real-time application! I imagine the DOSBox would barely notice the overhead for something less CPU-intensive, like a word processor. One of these days, I'm going to have to try Windows 3.0...

      I think most Windows desktop applications (database clients, productivity software) would have even less overhead than my old DOS games. But even if they had a lot more, consider the specs of a low-end Macintosh [apple.com]. Its CPU cycles as fast as my Dell's, and the raw crunching power of a G4 is possibly twice that of my PIII. Never mind a dual-processor G5!

      Which isn't all that expensive. If performance and usability were the only criteria for buying a computer, I'd be a Mac fanatic. As it is, I hardly ever touch one. Oh well.

      • You bring up a very good point about some apps being less CPU intensive. This could be useful for smaller appls that are win only, or even something like soulseek, which i dont support, but the mac versions of this have been lagging, and its not CPU hungry, just bandwidth hungry.
      • Windows 3.0 should be no problem - I ran it in software emulation on my 35MHz Archimedes, although the performance was not blazing fast. I think CPUs are now getting to the level where Win95 should be possible, after all the main factor affecting speed is available RAM.

        Still, you'd need some rather cunning dynamic recompilation to get anything less than a 10x slowdown in MHz terms.
    • Does it really need to emulate the win32s stuff. What would the performance be if the win32s stuff ran native on PPC and just ran an x86 emulator for the nonWINE .dlls and application code. All of the screen & IO API could be PPC native. The endian thunking layer may munge everything and destroy the speed though....
    • geez how dumb can people be, wine is definetly an emulator. It is not an x86 emulator, it is a windows emulator. Don't let the name fool you.

  • Bochs, WINE, X-Windows... (Score:3, Funny)

    by Llywelyn ( 531070 ) on Thursday January 29, 2004 @02:22PM (#8126400) Homepage
    What, is this a conspiracy to make Mac systems run more slowly?

    Cool idea, I wish them the best, but I like apps to load within my lifetime...

  • Not much different from 68K-PPC conversion (Score:5, Interesting)

    by wowbagger ( 69688 ) on Thursday January 29, 2004 @02:23PM (#8126415) Homepage Journal
    If you think about it, this COULD be done in a manner simillar to the way Apple handled the 68K to PPC conversion:

    You have BOCHS run the actual application code. When the code makes a call to one of Wine's libraries, you hit an escape sequence and drop to native PPC code for the actual implementation. At the end of the call, you resume emulation. It would probably require some changes in the shim layers between the DLL exports and the core Wine code, but it could be done.

    That worked well for MacOS because applications spent most of their time in OS code (which was native PPC). How well it would work for Windows programs remains to be seen.

    This has been kicked around a bin on Winedev.

    Disclaimer: IAAWD (I AM a Wine developer, in my own small way - I did some cleanup on the Joystick and ADPCM audio code).

    • Two things (Score:4, Insightful)

      by Llywelyn ( 531070 ) on Thursday January 29, 2004 @02:46PM (#8126698) Homepage
      ...that might throw a wrench in that, even assuming the apps do spend their time in system calls.

      0) The PowerPC was an order of magnitude faster than 68k series. IIRC the 601 had twice the clock and was faster per clock than the 68040. There is no such advantage here.

      1) In order to handle everything correctly here the bit-order is going to have to be switched (different endians). This is not fast on a good day.

      • Re:Two things (Score:5, Informative)

        by g_lightyear ( 695241 ) on Thursday January 29, 2004 @03:04PM (#8126915) Homepage
        Not necessarily. The technology being chosen is a combination of native code - which can do any necessary 'transitions' to a 'normal' endian mechanism at the API boundary between WINE and the application - and the emulator in question.

        The emulator in question is based on something similar to the FX! Alpha code recompiler; it provides an execution environment, yes, but also dynamically recompiles code into native.

        Between the core Windows libraries being "native" (in that they're wine lib, and therefore PPC-compiled native on OSX, not native x86) and the remainder in this 'recompiled' code execution environment, it's possible to strip out much of the endian issues.

        Not saying they will - only that there's a lot of room to manoeuvre here.

        Free.fr, where the project is hosted, is (of course) being slashdotted.

        One of the performance metrics lists the QEMU version of gzip (x86 on PPC) being 5 times slower than native (for example) - and comparison to bochs put bochs well behind (however, qemu had no MMU emulation).

      • Re:Two things (Score:5, Informative)

        by clem.dickey ( 102292 ) on Thursday January 29, 2004 @03:31PM (#8127273)
        > the bit-order is going to have to be switched (different endians). This is not fast on a good day

        That's byte order, not bit order.

        Even on a bad day dealing with byte-reversed integers on a PPC requires just two instructions: Load Byte Reversed and Store Byte Reversed. These replace the Load and Store which PPC uses for native data.

        Floating point load/store would suffer, though. You would have to use the integer unit to reverse the bytes, as there is no Load/Store Float Byte Reversed.

        Note that data in a PPC register has no endianness, because PPC registers, unlike PPC memory, do not provide byte or bit addressability. (The original POWER processor have an "extract bit" instruction which extracted a bit at (big-endian) position n in a register. This instruction was not carried forward to the PPC.)
      • i think PPC processors until the G4 are biendian, that is how virtual pc does some of its magic

      • Re:Two things (Score:3, Informative)

        by Lord Kano ( 13027 )
        The PowerPC was an order of magnitude faster than 68k series. IIRC the 601 had twice the clock and was faster per clock than the 68040. There is no such advantage here.

        The PPC was faster per clock cycle. In terms of actual clock frequency, the first PPCs were slower than the fastest 68040s. The PowerMac 6100/60 ran a PPC 601 at 60 mhz. The Quadra 840AV ran a 68040 at 80mhz (all IO to the logic board was done at 40mhz), near the end of the 68k's lifetime, Apple started to refer to such machines as 40/80 wh
      • actually, the 601/66 WAS faster, but mainly because Apple dumped clock doubling at the same time. A 33MHz Mac actually ran on a 66MHz 68040 chip, so technically, the chips were the same speed.

        This emulator had a couple of advantages though - first, no endian swapping (as you mentioned) and second, a trick called dynamic recompilation, where commonly used instructions or loops were stored in L1 or L2 Cache. The same developer went on to develop Virtual PC's dynamic recompilation engine for Connectix.

    • Re:Not much different from 68K-PPC conversion (Score:2, Interesting)

      by Anonymous Coward
      Actually, when the PPC initially came out, most of the OS was NOT yet rewritten as native code. Thus early PowerPC based Macs were only marginally faster than 68k Macs, but they sped up quicly as more and more of the OS was ported and the 68k emulation code was improved and more and more programs came out with native PPC support.

      Then there was a long hiatus. First, because Apple was retargeting its efforts at Copland (which turned out to be vaporware) and because the context shift between PPC to 68k code e

  • Unlikely to provide any speed (Score:3, Informative)

    by Anonymous Coward on Thursday January 29, 2004 @02:31PM (#8126520)
    Virtual PC may run reasonably quickly (still not what I'd call 'fast'), but that's because it used a horrible hack. All PPC processors up to and NOT including the G5 were bi-endian. VPC switched their endianness while it was running so it could do everything without swapping bytes. This is both the delay to further VPC releases and the reason x86 emulators will remain quite slow.
    • bi-endians don't like to be called that, please refer to them as homosexual.

    • Re:Unlikely to provide any speed (Score:4, Informative)

      by FredFnord ( 635797 ) on Thursday January 29, 2004 @04:38PM (#8128032)
      > All PPC processors up to and NOT including the G5 were bi-endian. VPC switched their endianness while it was
      > running so it could do everything without swapping bytes.

      Incorrect. It used specific little-endian processor instructions, but it did not put the chip into little-endian mode.

      And, oddly, Virtual PC's performance was never more than 25% or so greater than SoftWindows's performance, and SoftWindows never used them at all, and was a badly-ported 680x0 program by then to boot. So frankly, I have my doubts that this is really going to make that much of a difference.

      -fred
  • .. to get a computer that DOESN'T run windows. One that is faster, more secure, runs a more stable OS and is more powerful, just so that you can emulate a PC so it's slower, and less stable. Weird.
    • I agree. For me (and for most Mac users I know), there's no reason to run Windows over OS X any more. I've been using OS X for almost two years, and there's only been one program for the PC I wanted to run that didn't have a Mac port or Mac equivalent. And that was a game.

      I actually think for what I do (audio editing, sequencing, plus all the normal day-to-day stuff like web, email, etc.) the quality of the software avaliable for OS X is better than what you might get on PC. For example, there are a lot mo
    • Since you bought up the problem of cost why not make a PCI bus card or a firewire box that has a PC in it? A nice 386 PC or maybe even a pentium.

      the think is people are not going to be buying zillions of these things. So it may well be affordable at say 100 or 200 dollars to just get a hardware device rather then a slow software emulation. Now youjust have to emulate the bios and map the mac's IO onto the PC.

      • Since you bought up the problem of cost why not make a PCI bus card or a firewire box that has a PC in it? A nice 386 PC or maybe even a pentium.

        Orange Micro [orangemicro.com] used to make a few cards [orangemicro.com] that did this. i still have a OrangePC 550 [orangemicro.com] laying around. it's a K6-2/233 with it's own dedicated 256 MiB of memory and all the external ports you'd expect on an AT PC coming off a cable 'octopus' (save keyboard) - this thing even had it's own BIOS. this card only cost $200 or $300 less then getting a full blown PC, of the e

    • Re: (Score:3, Informative)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
      • The point is, there needs to be some software that will allow one to move to a mac, but provides some sort of transitional workaround until something native is available.

        try this [microsoft.com]* or this [sourceforge.net]

        if your still stuck in Mac OS 9, you can try this [lismoresystems.com] or even try to find this [fwb.com]

        you have a lot of options, open your eyes!

        *yes it's owned by Microsoft, but only recently. VirtualPC is still the product i would recomend if you need to run windows Software on the mac. G5 support is still an issue, but version 7 (shipping s

  • I don't mean to whine but... (Score:3)

    by amichalo ( 132545 ) on Thursday January 29, 2004 @02:42PM (#8126654)
    DISCLAIMER: My only experience with using X11 on OS Xis running OpenOffice via it.

    I am concerned that this will simply be too slow to be useful. Even with a 1Ghz G4, loading OO.o, which uses X11, is very slow (takes minutes to load). I could only imagine loading an exe via WINE via X11 via OS X would be an exercise in patience.

    Any info on minimum system specs or performance levels the project is targetting. (I tried to RTFA but there was little substance.)
    • X11 will not be the limiting factor here. In your experience with X11, it was OpenOffice that was slow. 1.0.3 was a terribly slow program. I use X11 on my Mac all the time, and it has no performance hit what so ever.

      I am, though, concerned for the speed of Bochs. I think it may be sluggish at best, but only time will tell. And for simple Win32 programs, this may just be the way to break people out of the Windows trap.

      Mewyn Dy'ner
    • are you using oo 1.0.3? cause tat loads slow when running a custom compiled versio on gentoo x86. Once they have oo 1.1 (they might already; i haven't checked) for OSX, it'll be much faster. It is on linux.
  • As it's been said here, Wine is not an emulator. The reason it works as well as it does is BECAUSE it's running on x86 hardware. Having it emulate x86 is going to really bog it down. I seriously doubt it will work better than VirtualPC. However, if they can get hardware vidoe acceleration working, then it might just be worth it.
    • With this solution windows system calls will run native, with VirtualPC they run emulated. Could be faster if they speed up bochs. Looking at the site it seems they are going for QEMU though (FAQ) [bellard.free.fr]

    • As it's been said here, Wine is not an emulator. The reason it works as well as it does is BECAUSE it's running on x86 hardware. Having it emulate x86 is going to really bog it down. I seriously doubt it will work better than VirtualPC. However, if they can get hardware vidoe acceleration working, then it might just be worth it.

      Video acceleration comes free, through a few layers of abstraction. Basically, the windows program will call some Win32 API function
      FooDrawTextlpsz(string);

      The CPU emulator r
    • WINE replaces the Windows API calls with X equivalents (and maybe now Quartz?), so it's faster because WINE Is Not an Emulator, it is native code replacing APIs called from a Windows App. You need an emulator to translate the program being run but any calls to Windows APIs are run natively. The speed cost will be how much time is spent in the emulated code rather than the actual Windows API code.

      Windows itself is (mostly) abstracted from the hardware anyhow, which was done initially to support Alpha p

  • Soft Foundation (Score:2, Interesting)

    by metrazol ( 142037 )
    I'd love to see WINE on OS X but will it run any faster than Dosbox? I know you're thinking "Oh, great, he's comparing WINE to a game environment emulator." but hey, it's the same problem. Dosbox emulates a 286 or so wholesale, which is...well...useful for old DOS games, but can Wine promise anything more? WINE is, obviously, not an emulator, so it has to work on top of an actual emulator. Dosbox is slow. Bochs is slow. WINE is fast...on a high end x86. WINE won't run so well on your old 386. So if WI
    • Maybe your getting this, and maybe not, from your post it sounds like your not understanding.

      Wine itself will be fully PPC compiled, it won't be emulated at all. That includes all wine native .dlls (which includes the most commonly called ones). It will only be actual windows dlls which will have to be emulated to run.

  • Just Goes To Show... (Score:5, Funny)

    by Flwyd ( 607088 ) on Thursday January 29, 2004 @02:49PM (#8126739) Homepage
    All problems in Computer Science can be solved by adding another layer of indirection.

  • Not using Bochs... (Score:5, Interesting)

    by BlueSteel ( 597448 ) on Thursday January 29, 2004 @02:52PM (#8126782)
    According to their FAQ, they aren't using Bochs for x86 emulation, but QEMU [bellard.free.fr]. I have no experience with QEMU, but according to some of the posts on Darwine's sourceforge message board, it's much much faster than Bochs. I wish these guys luck. I'd love to have wine running on OS X.

    • Re:Not using Bochs... (Score:5, Informative)

      by nathanh ( 1214 ) on Thursday January 29, 2004 @03:44PM (#8127417) Homepage
      According to their FAQ, they aren't using Bochs for x86 emulation, but QEMU. I have no experience with QEMU, but according to some of the posts on Darwine's sourceforge message board, it's much much faster than Bochs. I wish these guys luck. I'd love to have wine running on OS X.

      The reason QEMU is faster is because of dynamic translation.

      Bochs decodes each and every instruction just before it is executed. So if you have a loop that executes 100 times, you have to decode the same instructions 100 times. That's incredibly slow. I have seen estimates that Bochs needs 160,000 native CPU instructions to emulate a single x86 instruction.

      QEMU takes a block of code (typically a whole page) and translates the block into the native instruction set. Then it executes the translated block of code. QEMU tries to keep translated blocks around as long as possible, using dirty bits to determine when retranslation is needed. This is the same technique used by VirtualPC on the Macintosh. It is much faster than Bochs!

      There is experimental code in Plex86 to do dynamic translation and Bochs can use Plex86 as the backend (it offloads entire pages of code to Plex86). So it's possible that Bochs will one day achieve the performance of QEMU.

      Take note that QEMU is usable today, just so long as you're running purely Linux binaries. It is possible to use QEMU to run Linux/x86 binaries on Linux/PPC for example. QEMU's dynamic translation engine is pretty decent. QEMU doesn't emulate the PC hardware. Bochs does emulate the PC hardware. If you could cherry pick the dynamic translation from QEMU and the PC hardware emulation from Bochs then you'd have something to compete with VirtualPC right now.

      • Re:Not using Bochs... (Score:3, Informative)

        by caseih ( 160668 )
        Actually QEMU has mode where they are emulating the hardware. Right there are reports of windows 98 booting in the full virtual machine that qemu can now do. Obviously the linux binary loader part of qemu is faster and lighter, but qemu is a full emulator/virtual machine, soon to be on par with bochs and maybe virtualpc. There's even talk of using the qemu dynamic translation engine in bochs instead of the slow mechanism it currently uses.

        Note that this darwine project is not a virtual machine per se, b
        • Actually QEMU has mode where they are emulating the hardware. Right there are reports of windows 98 booting in the full virtual machine that qemu can now do.

          That's great! The last time I checked I knew it was in development, but I didn't realise how fast the work has been progressing. Truly amazing.

  • Bochs? (Score:5, Informative)

    by CODiNE ( 27417 ) on Thursday January 29, 2004 @02:53PM (#8126790) Homepage
    I don't know where all this Bochs talk is coming from. I checked the FAQ and looked around some links and never saw it mentioned. QEMU on the other hand seems to be what they're putting in the official release. Maybe Bochs is in there for now for compatibility reasons. QEMU is waaaay faster than bochs, I can't wait til this is packaged up in a DMG that I can recommend to my OS X buddies.

  • Headf*ck!! Difficult to understand... (Score:3, Interesting)

    by polyp2000 ( 444682 ) on Thursday January 29, 2004 @03:04PM (#8126912) Homepage Journal
    This is a really weird one, and it is difficult to say how fast or slow it might be.

    Many of the core Win32 api's and DLL's have been re-implemented as Linux native equivalents as part of the wine project. If these are compiled as linux ppc versions, and you have an x86 emulator running the non-ppc bits, you get a really bizarre hybrid of code executing. It will be really interesting to see how this works. Its also pretty difficult to say how fast or slow this thing is going to be, due to the strange architecture. My brain is having a confusing time trying to figure out how they would string these components together.

    Nonetheless, good luck to them, its an ambitious project and probably has some far reaching implications for the future.

  • Lemme get this straight... (Score:3, Insightful)

    by Ianoo ( 711633 ) on Thursday January 29, 2004 @03:28PM (#8127241) Journal
    Let's see now:

    x86 assembler instructions translated to PPC assembler instructions (two fundamentally different microarchitecture designs, CISC vs RISC and endian issues) using the Win32 API translated to Xlib (X Windowing System) talking to Apple's X Server translated to PDF commands and sent to Quartz.

    Can you say "speed demon"? If you need to run Adobe Illustrator that badly, then at this sort of speed it'll probably be easier to decompile it, port it and recompile it!

  • some people (Score:5, Funny)

    by Enrico Pulatzo ( 536675 ) on Thursday January 29, 2004 @03:37PM (#8127334)
    will do anything to play minesweeper.
    • Well, I do have to say that I have yet to find a version of minesweeper on Mac OS X that is as good and/or easy to play as the one that comes with windows.
    • The US government won't even sign the international land mine treaty! Mines kill a person every twenty minutes, are damn tough to clean up, the US spends hundreds of millions every year cleaning up American landmindes...

      Some people really WILL do anything to play minesweeper.

      -fred
  • The To Do list shows 15 tasks, one guy working on 4 (one finnished), one on another, and 3 working on the most important one: Improving the Webpage. The rest has yet to be assigned.

  • I thought it was a typo at first.

  • How about me? (Score:3, Funny)

    by blackmonday ( 607916 ) * on Thursday January 29, 2004 @04:38PM (#8128020) Homepage
    Anyone know when WINE is getting ported to Windows?

    • Obviously Microsoft already integrated the BSD-license version.

      (How many people will get this post?)

    • Re:How about me? (Score:3, Informative)

      by wowbagger ( 69688 )
      Anyone know when WINE is getting ported to Windows?


      Actually, there is an effort to port Wine to run under MinG and Cygwin. The idea is that you could run a program under native Windows, then run it under Wine, and observe the differences. Then you try to make Wine more like Windows.
  • I've had this idea for a long time (and obviously I wasn't the only one), but I'm not skilled enough to do it. I'm glad somebody's doing it, and I can't wait to try it.

    A previous poster said they didn't think it would be very fast. In VPC, the slowest stuff is graphics. A native Win32 API would handle graphics crap natively, which would be a heckuva lot faster, probably faster than VPC's special graphics driver approach. As to how much time most windows apps spend in the APIs, I wouldn't know... but consid

  • Convert x86 binaries into PPC? (Score:3, Interesting)

    by Slur ( 61510 ) on Thursday January 29, 2004 @06:20PM (#8129163) Homepage Journal
    There is but One Rule for computational speed: "To make it go faster, make it do less."

    WINE is smart because it re-implements many Windows DLLs natively. QEMU is smart because it caches and executes native code built from x86 code. Taken together the speed should be noticeably better than VirtualPC.

    But the most optimal method by far would be to convert x86 binaries into PPC application packages that link to native libraries / frameworks corresponding to Windows DLLs. Such translated binaries would require no emulation layer, just the presence of the necessary libraries.

    But can you imagine how complex it would be to convert x86 code into PPC code? And yet part of me thinks this brute-force method is almost trivial. It's simple enough to disassemble machine language. And one could certainly disassemble x86 code into a working C equivalent where C variables correspond to x86 registers.

    Besides the fact that this would be an exacting and laborious task, what other barriers exist for this approach?
    • No, the MOST optimal method would be to slap a duron and 256MB ram, and an integrated chipset (SIS?) onto a PCI card and have this WINE-on-Mac implementation execute the x86 code on the x86 processor. All the calls to the API would then get routed to the PPC-native WINE implementation.

      Hell, I'll bet even a C3 or Transmeta chip would do better than an emulator.

      Apple could sell the cards at a profit for under $200.

      Emulation not fast enogh? Upgrade the card to a faster version, maybe they should have two if


  • No so much from the perspective of getting apps running on the Mac, but from from the perspective of getting Apple interested in this way of getting apps running on the Mac.

    From my understanding wine itself already compiles 100% PPC including wine dlls. Now all a developer has to do is port their own functions to PPC compilable code instead of rewrite from scratch.

    A HUGE chunk of the work in a gui windows app is dealing with the win32api. Porting to the Mac means rewriting all this... now it doesn't, n

  • They really screwed up this article - QEMU (Score:4, Insightful)

    by Corpus_Callosum ( 617295 ) on Thursday January 29, 2004 @10:22PM (#8131225) Homepage
    Unfortunately, this write-up is totally screwed up. The intended emulator is QEMU, which can already be used on PPC/Linux to run Wine at speeds aproaching native speeds. I posted a link to the forum where this is discussed elsewhere, but here it is again [sourceforge.net].

    QEMU is a dynamic translator that decompiles x86 executables and recompiles them into PPC, caching the results. You can find the qemu project here [bellard.free.fr].

    Not only will this work, but it will work FAST. In fact, it will probably even be possible to drop windows DLLs onto your mac in the same way that you drop them onto Linux in order to get Wine to work better (using native windows DLLs instead of Wine clean-room versions). Remember, QEMU is a dynamic translator.

Slashdot Top Deals

To be awake is to be alive. -- Henry David Thoreau, in "Walden"

Close