Bertho Stultiens <[EMAIL PROTECTED]> writes:
> According to what I found on the web are resources always little-endian
> because MS does not support/wrote OSes for big-endian processors. There
> are a couple of questions that go with this:
>
> - Is it true that MS only has little-endian version?
The Windows headers contain a few #ifdef _MAC that attempt to add
big-endian support (apparently using a generic #ifdef BIG_ENDIAN was a
concept a bit too abstract for Microsoft); but I'm not sure if they
ever addressed the resource issue. All platforms that NT (used to) run
on are definitely little-endian.
> - 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).
Yes, I think resources can be considered a binary format that is
defined as little-endian. We probably even want to present the
resources to the application in little-endian format; this will
require changes to the source code, but the probability that code
manipulating resources works out of the box on other CPUs is pretty
small anyway, no matter how clever we try to be.
> - Who has tried to run wine(lib) on big-endian processors and what are
> the experiences?
I know Gav had the Winelib samples running on powerpc, the main
problem was that cursor positioning swapped x and y coords probably
because of MAKEPOINT and related hacks.
--
Alexandre Julliard
[EMAIL PROTECTED]
