Slashdot Mirror
WINE for Mac OS X in Development
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!"
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.
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.
Cwm, fjord-bank glyphs vext quiz
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).
-- A mind is a terrible thing.
> 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.)
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.
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.
I've had this sig for three days.
You are not alone. This is not normal. None of this is normal.
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.
www.eFax.com are spammers
Well, try viewing Visio VSD documents under a Mac. Not possible. And for those of us who are network guys, and need to use visio for work, it kind of puts a damper on having a shiny new mac sitting on my desk.
OmniGraffle supports VSX files, but not VSD, which is what everyone is using because Visio defaults to the VSD format when saving.
There are other various apps too that just do not exist on a Mac, but get used by network guys and only run under windows (typically config compare programs, cisco password crackers, etc)
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.
Need Free Juniper/NetScreen Support? JuniperForum
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.
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 used to make a few cards that did this. i still have a OrangePC 550 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 era (AKA $850 for a PCI card!)
the trick is that it hijacked the mac monitor, keyboard, and mouse while it was in use. it had a mac program running that hosted hard disk images (like virtualPC) for the PC to actually work. the host application also provided a few other VPC features like clipboard shearing.
sadly, virtualPC running on a 500 MHz G4 is just as fast, and the card isn't even supported on Mac OS 9 anyway.
it'd be interesting if a darwine type project could act as a new host for this card, custom OS and all....
(Apple used to make a similar card and setup, and even bundled it with a few older macs - Performa 640, PowerMac 6100/DOS, ect. they even advertised this on TV!)
Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
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, but a windows exe loader and api/ x86 code interpreter. The goal being to run windows exes on OS X as if they were native (this does not mean it has anything to do with quartz). In some respects, darwine could be compared best with the qemu linux loader portion of their project.
Take a look at their forums where this question was asked: qemu, not bochs
The reason that it can be true that 1+1 > 2 is that very peculiar nonzero value of the + operator
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 runs along fine and dandy until it hits this point, and needs to jump to the Win32 native API code. It calls WINE for this.
WINE is a natively compiled PPC application / library, so FooDrawText is just native compiled PPC code.
WINE takes the Win32 function, and uses an Xlib equivalent. XFooMakeStringGetDrawn(string, MONACO) or whatever.
The X server takes this Xlib call, and passes it to the Aqua drawing system, because on Mac OS X, the X Server is just an Application running alongside other native Apps.
So, Aqua draws the text into the window at the correct position, just as windows would on a native system.
This window is treated as a texture object.
The texture is used by the Quartz Compositing engine to draw the window to the screen by using OpenGL.
OpenGL takes the instructions to draw the windows, and hands them off to the video driver.
The video driver then instructs the card to finally draw the window onto the screen, using native commands for the specific card.
Lo and behold, the X86 Win32 request to draw text has resulted in a picture of some letters in our frame buffer.
Egad, I should probably take up baking.
So, anyhow, my point is that the Wine/ppc guys don't need to write an emulator for the video hardware. Though it's heavily abstracted, they get video acceleration for free thanks to the existing Xlib code. The Win32 application never touches the actual video device - it just makes API calls which make things happen to the hardware. Now, if this were a DOS emulator, it'd be completely different. You would need to actually emulate a VGA card that the program can have to itself.
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 when talking about their speeds.
Running 68k code the Quadra 840 would pound a 6100/7100/8100 into the ground. When more Apps started to come compiled for the PPC, that was when they really started to shine.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
IIRC, some of Aspyr's games are merely "wine-ized" versions of their Windows games. This is probably a licensed version of Wine. It has the potential to make the porting process easier, since there is no real porting of the code, if it is stable I can't blame them, but customizing it to the OS instead of emulating it would have been a nice touch. NOLF 2 and Simcity 3000 being the first that pop into my mind. Also, they get kinda funky if you try to save on a different partition than the game is located.
I hate sigs.
once you do that; you basically made your emulator a runtime environment instead (with CPU emulation).
It's not really a new idea; it's however indeed alot faster; but it comes at a cost of compatibility.