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]