Wine Emulation: Swapping functions

Pierre d'Herbemont stegefin at free.fr
Wed Aug 25 09:22:41 CDT 2004


 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 at free.fr> wrote:
>>
>> On 24 août 04, at 22:50, Alexandre Julliard wrote:
>>
>>> "Pierre d'Herbemont" <stegefin at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/darwine-devel





More information about the wine-devel mailing list