From the limited experience I have the problem is that if a portion of code expect to have a certain type of endianness, it would make some special assumption, we won't be able to track out (See [1]). And it will be even harder to track the issues for the x86 already compiled code, in Wine we can for instance track the specific function that cause troubles and replace it with safer functions (see strcmp, strlen...).
Finally I think we should only relay on call conversion, and that my swapping on-the-fly technics is not sure enough to be applied here.
Pierre.
[1] http://stegefin.free.fr/wine/
On 25 août 04, at 14:37, Pablo Bendersky wrote:
Not sure if what I'm thinking would even work, but let's mention it. Could we add the swapping to qemu? We would end up with a x86 emulation that used big endian instead of little endian. This way, all memory accesses (from the wine api) would end up unswapped, while the method calls from the .exe files would be swapped (as they will be emulated). Is this a viable alternative?
On Wed, 25 Aug 2004 13:32:22 +0200, Pierre d'Herbemont stegefin@free.fr wrote:
On 24 août 04, at 22:50, Alexandre Julliard wrote:
"Pierre d'Herbemont" stegefin@free.fr writes:
Hi Alexandre,
This patch allows to load a PE exe to memory. You may notice that there is no "mass" byte swapping. The technics used here is a bit developer here: http://stegefin.free.fr/wine/ You might prefer a more conventional way of doing the byte swapping, in this case tell me. We might still need this approach since it could efficient for sharing data accross the LE exe and the BE winelib.
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 litlle endian, but we are coming to the limitation of this method.
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.
I agree it is easier, but as mike pointed we can't easily access OS X API, though I am sure there is a way. Anyway I would like to give the emulation inside method a try. I think using automatically generated wrapper can work for most APIs. For sure it won't be easy but I think there is hope in succeeding. I'll also try to add to qemu the darwin-user target, so we can see the limitation of going this way ;)
Pierre.
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Darwine-devel mailing list Darwine-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darwine-devel
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Darwine-devel mailing list Darwine-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darwine-devel