Hello,
> 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?
As far as I know, yes. (I've checked the various NT versions on
the MSDN disks; they're all little-endian at least ... Don't
know about all the WinCE versions, though.)
> - 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).
I agree, resources should always be treated little-endian.
At the most, we might think about making a distinction between the
resource data itself and the 'meta data' surrounding it (resource
directory, PE header links ...); it might be easier to have the latter
in native byte ordering, especially in the case of the dummy PE headers
created for Wine modules (these structures are completely internal
between wrc and the Wine loader, so we can use whatever is easiest
here, of course).
Every 'external' format, be it .RES file or cursors/icons/etc. imported
by or included in RC files, should IMO always be little-endian. The
same applies to the raw resource data exchanged between app and Wine,
e.g. when using a Create...Indirect routine.
> - Who has tried to run wine(lib) on big-endian processors and what are
> the experiences?
I actually got the 'hello3' libtest app to run under Solaris (32-bit
big-endian) some time ago. I never sent in the patches as I didn't
get around to clean them up properly, but I think I recall the major
problems:
[ I decided to have resource contents in little-endian, and meta data
(resource directory) in native big-endian format, as this seemed to
be the solution requiring the fewest Wine changes. The changes
described in the following achieved this result. ]
- wrc wouldn't compile RC files with inlined cursors/icons, as it would
interpret the (hard-coded little-endian) numerical values as big-endian.
To fix this, the split_icons/split_cursors routines have to be
re-implemented.
- Reading in .RES files in wrc also needs to take into account that those are
in little-endian format. This requires changes in readres.c: the get_(d)word
macros need to byte-swap, and the 'emptyheader' can't rely on a struct
to get the correct file image of the dummy Win32 header.
- In the assembler files written by wrc, .word is used for 16-bit quantities.
Unfortunately, on Sparc (and probably others) .word generates 32-bit.
We should use .short or .half instead.
- To write out resource contents in always little-endian format, byte-swapping
has to be done at various places in genres.c
- Wine has to read in resource data in little-endian format. This means
that the GET_DWORD etc. macros in windef.h need to be restored to their
original byte-swapping semantics.
Furthermore, at some places in the resource processing code those macros
weren't properly employed. The most obvious problem is in the handling
of Unicode strings: wide characters are also endianness-sensitive,
of course, so a simple lstrcpyWtoA doesn't do the right thing ...
- Even with the decision to have the resource directory in big-endian
(the current use of the assembler/linker to provide relative fixups
makes anything else difficult), the pe_resource.c routines still don't
work, as they rely on various bit-field structures to break out the
'resource name is string' and 'resource data is directory' bits.
This doesn't work, as on Sparc bit-fields are allocated starting from
the MSB down, not LSB up as on Intel :-/ Fixed by direct bit arithmetic
on the whole DWORDs instead of using bit-fields.
[ Note that there are various other, non-resource-related problems to
be fixed before the libtest app actually runs :-/ ]
If you're interested, I could send you my old patches ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
