Folks,
Few things remain before I'm satisfied with the state of wrc. Here is a list of them: -- the -B option: I think this is a the wrong interface. The Win32 API has been ported to Big Endian machines IIRC, and there is no point allowing people to mock with alignment like so: it opens up a BIG can of worms for future support and maintenance. And I don't see how it can be useful -- the Wine code assumes a certain endianess, and that's exactly what wrc should output. NOTE: Of course, I just realized that the argument holds as long as the .res format has a fixed endianess on all platform. I hope it does. Anyone cares to enlighten me?
-- we may need a -r option for compatibility with rc. rc used to have a -r option, it is now ignored for backwards compatibility. Anyone know if this is old enough that we can safely ignore? Up to what version was the option required? It is curretly used in the Mozilla source, so we were wondering if we could remove it from there as well.
-- the -m option. rc doesn't have it, why do we need it? We are using it in the Wine tree, do we really need it? Personally, I'd be happier if we could get rid of it, so we don't depend on Wine-only extensions.
-- I would like to add a -U option (undefine), for compatibility with rc. In fact, wpp should support it as well, for compatibility with cpp.
That's it. Any more ideas? I would like to get this out of the way soon, any comments or suggestions are most welcome.
"Dimitrie O. Paun" dpaun@rogers.com writes:
-- the -B option: I think this is a the wrong interface. The Win32 API has been ported to Big Endian machines IIRC, and there is no point allowing people to mock with alignment like so: it opens up a BIG can of worms for future support and maintenance. And I don't see how it can be useful -- the Wine code assumes a certain endianess, and that's exactly what wrc should output. NOTE: Of course, I just realized that the argument holds as long as the .res format has a fixed endianess on all platform. I hope it does. Anyone cares to enlighten me?
No there's no standard, and there's no defined Win32 API on big endian machines. It's not clear what is the right thing to do, currently we use native endianness in Wine, which means a different .res format. This implies that we need to be able to specify which one we want, if only to allow cross-compilation.
-- the -m option. rc doesn't have it, why do we need it? We are using it in the Wine tree, do we really need it? Personally, I'd be happier if we could get rid of it, so we don't depend on Wine-only extensions.
We used to need it, but I think I have fixed all the offending resources now, so it should be OK to remove it.
On 26 Mar 2003, Alexandre Julliard wrote:
No there's no standard, and there's no defined Win32 API on big endian machines. It's not clear what is the right thing to do, currently we use native endianness in Wine, which means a different .res format. This implies that we need to be able to specify which one we want, if only to allow cross-compilation.
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
If MS ever decides to support big endian arches, and they do the wrong thing, we have all the code in there, we can add the option back with a few lines of code. But currently we are defaulting to the least likely option, and the least desirable at the same time.
"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...
On March 26, 2003 01:46 pm, Alexandre Julliard wrote:
Resource data is visible from the application, and most apps will handle it as native endian.
Yes, I missed that one. I'm happy with the current state of things, thanks for the clarification.
-
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun