This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: windres RC codepage

Vlada Macek wrote:

> Each of his two results (2.13.90 and 2.15.91) is different, but none is
> ok, no UCS-2 as I expect.

Well, apparently windres does some sort of codepage conversion when
compiling RC input.  It isn't trivially obvious to me why this is, so
I'll need to investigate further.

This behavior is equivilent to Microsoft's RC, so windres is doing the
right thing.  However, Microsoft's RC has a /c option to set that
codepage to Czech, or whatever, and so fix this problem.  Unfortunately,
windres does not have a similar option.

> What should be the best solution?

Ideally, someone would add a similar option to windres.  It probably
would not be difficult to add, but I can't say for sure yet.

I don't understand at all what sort of transformation of encodings is
being done.  If I use windres to compile your Czech input file (with
whatever encoding is default for US English WinXP), then decompile it
back to a RC file, the text I start with is not the same text I finish
with.  This seems very odd:

Actual Czech string: PÅÃliÅ ÅluÅouÄkà kÅÅ ÄÃbelskà Ãdy PÅÃLIÅ ÅLUÅOUÄKÃ
String in my native codepage: PÃÃliÅ ÅluÂouÃkà kÃà ÃÃbelskà Ãdy PÃÃLIÅ
String after conversion: PÃÃli1 eluÂouÃkà kÃà ÃÃbelskà Ãdy PÃÃLI0

Anyway, I'm going to look at this a little more, and see why this
happens.  In particular, I'm going to look at the sources, and look for
a description of the binary resource representation.  If anyone else
knows more about the encoding of resources strings, speak up! :)

Aaron W. LaFramboise

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]