This was supposed to have been sent last week, but it looks like it never
made it out of the Corel email gateway....

Bertho Stultiens wrote:
> - Should wine only use little-endian in the resources? In my oppinion,
> yes. Let the resources be the same all the time and let the
> resource-loader take care of conversion. There is a comment in a header
> about byte-swapping and wrc. I really would prefer to have byte-swapping
> in wine rather than wrc. Mainly because wine already requires to do the
> analysis of resource-contents, whereas wrc only packs data (without
> contextual/semantical knowledge).
> 
> - Who has tried to run wine(lib) on big-endian processors and what are
> the experiences?

I had clock and at least one other app up and running on LinuxPPC about 
a year ago.  I just let wrc spit out native (big) endian data, and with the
byte swapping turned off for the wine PUT_WORD/GET_WORD macros, the things
I tried worked fine.  I didn't have any bitmaps, or any complicated rc files
though.  

I'm not sure I see the benefit of forcing little-endianness in the resources.
If you're on a different CPU, you're not going to be able to load an x86 
PE file anyway, so why not just output in native-endianness?  IE: (convert
cursors, icons, etc).

If wrc outputs everything in little endian format, that means that WINE has
to do byte-reversals at runtime.  The performance lag is probably minor, 
but why not shift the burden to build time?  I don't think that there are
all that many resources types this should affect in wrc - just cursors, 
icons, and bitmaps, I think.

As for the CreateXXXIndirect routines, the ideal thing to do would be to 
support both little-endian and big-endian data where possible.  For example,
CreateBitmapIndirect could check the depth field: if the data is in the 
wrong endian-order, it could activate byteswapping code.  This would mean 
that apps can both dynamically generate their own data to pass to 
CreateBitmapIndirect, *or* they could just do a simple load from a BMP
file.  Actually, this is really unlikely to affect anything other than 
bitmap data - very little else is generally loaded from data files. 

This is roughly the approach we took with MacPort for bringing our 
graphics apps to the Mac, except that the resource compiler actually 
spit out data that was not only in native endian format, but also 
in a format nearer to what the OS used for that data.  IE: BMP input 
was converted to a format that was a direct representation of a Macintosh
PixMap.

-Gav

-- 
Gavriel State
Gainfully Unemployed Guy
[EMAIL PROTECTED]

Reply via email to