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
the
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
of
this method.
Here is what I'm proposing...
void * memcpy(void *dst, const void *src, size_t len);
becomes
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@free.fr 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 (http://www.bellard.org/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 manage.
Regards, Roderick Colenbrander
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl