WINE for PowerPC?
wine-devel at sun.consumer.org.il
Sun Nov 3 11:36:13 CST 2002
Zsolt Rizsanyi wrote:
>On Sunday 03 November 2002 02:26, Dustin Navea wrote:
>>--- Adam Ernst <adam1234 at athenet.net> wrote:
>>>I'm sorry if this is off topic or doesn't belong here. I'm not a
>>>developer (at least not in C) so I'll wait a few years while I learn C
>>>before I come back and help you guys. But I was wondering...
>>Ok, I dont want to sound rude, but you should be glad anyone is replying...
>>Its not really off-topic as there arent any set topics and it certainly
>>doesnt not belong here.
>>>What are the technical issues with putting WINE on the PowerPC? So
>>>someday we could run WINE with native Windows apps on Linux for PPC or
>>>even (!) the Macintosh? (Mac OS X is Unix based, so...) Is it feasible
>>>to put a x86 emulator in there, so Win32 apps will think they're on a
>>>standard x86 processor?
>>Do you know all of the routines for an x86 processor? Neither do any of us
>>;). If we put in x86 emulator in there then we need a hardware emulator
>>also so that it translates the codes from x86 hardware codes to mac ones.
>>And the only hardware emulator I know of (even for x86) is vmware and it
>There is bochs (bochs.org) which is a true hardware emulator of x86 machines.
>It runs on many architectures (AFAIK it runs on PPC). It has stable releases
>and it is open source.
>The only drawback is that it is really slow, because all x86 instructions have
>to be emulated. The installation of windows 9x takes some hours.
Does bochs employ JIT compilation? I know that even modest JIT support
provides great runtime improvement.
>You could try to merge wine with bochs, and you would get a windows emulator
>on PPC. But it would be really slow, so there is no use for it.
>If there will be use (like if the hardware will be fast enough, and
>architecture other than x86 will be more common) the merge will occur pretty
I believe you are wrong. Sure, emulation is not as fast as native code,
but that's exactly why a merged wine+bochs may be much much faster than
installing Windows in a VM.
In the former case, you find that only the native app requires actual
emulation. As soon as OS code (wine, in this case) is called, you switch
to native mode, and take it from there using native calls.
What is required in order to do that:
1. Winelib must be fully supported on that platform.
2. Endianity conversions must be performed on all >1byte values. This
means that the native code must work with structures that are little
endian. Personally, I'm not sure why that does not hold true to winelib
apps as well.
3. The CPU emulation need to be extracted from your emulator, as that is
the only thing necessary for such a setup. There is no need for any kind
of hardware emulation, as all hardware access is translated to native OS
It is, in fact, point #3 that makes this combination faster than running
a full blown emulator. It also holds true to the Wine name - the wine
code is not used (is not) as an emulator.
More information about the wine-devel