Re: WINE for PowerPC?

[Shachar Shemesh]

Zsolt Rizsanyi wrote:

On Sunday 03 November 2002 02:26, Dustin Navea wrote:

--- Adam Ernst <[EMAIL PROTECTED]> 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
royally sux.

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

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

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.

Regards
Zsolt