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!"

Comments

wwwwoooorrrrrkkkkk

[soboroff]

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

Re:wwwwoooorrrrrkkkkk

[forsetti]

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

[Cecil]

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.

This will be really slow

[NanoWit]

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

[radicalskeptic]

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.

Two things

[Llywelyn]

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

Lemme get this straight...

[Ianoo]

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!

Re:This could be a very good thing...

[Quobobo]

At the same time, this would really discourage development of native OS X apps, and I think we'd probably get a lot of very shoddy quick-recompile jobs. Could be a double-edged sword.

They really screwed up this article - QEMU

[Corpus_Callosum]

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.

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

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.