Wine on ppc/linux.

Mike Mestnik mmestnik at
Wed Jun 14 14:26:40 CDT 2006

On Wed, Jun 14, 2006 at 07:56:29PM +0200, Roderick Colenbrander wrote:
> > I'm trying/working to get x86 windows programs to run under linux on a
> > ppc and eventually a sparc.
> > 
> > After reading the Darwine list, I'm not sure where the best place for
> > this.
> > 
> > Will the current move by Apple to x86 hardware replace this project?
> > What about alpha, ARM, MIPS and sparc?
> At the moment Wine can be used on ppc/linux for porting programs using winelib. There have been discussions in the past about using wine to run x86 applications on non-x86 architectures. One of the proposals was to integrate an x86 emulator in wine. It was decided that it was very difficult due to little/big endian and other reasons (search the archive).
All the endian issues are resolved when the program is built for the
ppc system.  So I guess the real problem is that wine uses the wrong
byte order in it's windows ABI when built on ppc, it does not match
that of an x86 binary.

> I think you are going in the wrong direction with this; the right way
> IMO is to compile Wine for x86 and run the whole Wine+app under the
> CPU emulator. Otherwise you'll have to write wrappers for each of the
> 15,000 APIs.
Hmm, eventually the byte swapping has to happen.  The trick is not to
fix the binary app, but to provide the correct socket for it to fit
into.  If the app is 32LE then we need to load the 32LE library, like
wise for 64bit applications.

FWIW this all sounds failure, the DRI project was successful with
accessing a LE video card on an BE system.

The trick is to typedef things correctly, using an internal set of
types so that you can build different binarys for each target.  This is
something like a white-space clean up, where you change the code but
you don't change the binary.

I'd like for every one to consider doing this.  It would be good to
isolate the typedefs exported to the application from what the OS
exports to the library.

>>> It doesn't seem very efficient to trap on every memory access...
>>> Besides, I don't see how this can possibly work, there is no 
>>> guarantee
>>> that the compiler is going to generate accesses that always match
>>> size of the requested type, memcpy() being the obvious example.
>> I agree. though memcpy would need a wrapper which would set the dest
>> memory region to little endian, but we are coming to the limitation
>> this method.
Here is what I'm proposing...

void *
     memcpy(void *dst, const void *src, size_t len);


wine_app_void *
     memcpy(wine_app_void *dst, const wine_app_void *src, wine_app_size_t len);

Since wine_app_void is LE for a LE app and BE for a BE app, no byte
swapping need be performed.  The build system would choose the correct
format for the given application target and the buffer would stay in
that format.

"Pierre d'Herbemont" <stegefin at> writes:

> As a conclusion, would accept that we swap (using the regular way) the
> headers in order to load exe on a Big Endian host? (since the exe
> headers are Little Endian for each NT implementation)
Once again, ""we don't do any byte swapping"", we use the correct
typedef when reading these fields.  We can cache in native format, but
we always read and write in the same format windows would have.

> The other way which I think still works is to use qemu ( to load an x86 version of wine (you need an x86 glibc and so too). This method already works and is a lot easier than integrating an x86 emulator in wine and second wine with a builtin emulator might be as fast as an optimized qemu.
> So wine can be used on ppc/linux using qemu and a real port is way too complicated.
This is only limited by the current state of wine and how separated
the current typedefs are.  This should be easy to covert to and

> Regards,
> Roderick Colenbrander
> -- 
> Echte DSL-Flatrate dauerhaft für 0,- Euro*!
> "Feel free" mit GMX DSL!

 *   Mike Mestnik: Junior Admin          612-395-8932           *
 *      mmestnik at              VISI/Digital North       *
 Alt address: collections at

More information about the wine-devel mailing list