"Dimitrie O. Paun" dimi@intelliware.ca writes:
Yes, as I noted, I realized that the option would be needed if we use native endianess. But I would strongly argue that this is Not Right (TM). FS design has tought us that data should be stored in a single endianess. It makes sense -- you could move the file from one machine to the other, etc.
I think the right thing to do is: -- modify Wine to always read stuff in little endian -- remove the option, and force little endian output
I don't think it's feasible, and it's not clear at all that it is the right way. Resource data is visible from the application, and most apps will handle it as native endian. If you want to change that, you will have to add byte swapping code all over Wine plus all over the applications, for the very small benefit of exchanging .res files across platforms. I don't see any need for that; .res can be considered more like an object file format, and you don't expect to share .o files across platforms either, you simply recompile for your target.
P.S. Didn't NT 3.1 use to support MIPS? Isn't that big endian?
No, NT was always little endian; on MIPS and PowerPC you can have both modes. On Sparc you are stuck with big endian, and by a strange coincidence NT has never been ported to Sparc...