I have an RC file which compiled fine using windres 2.18.50.20080109 (Mingw, under Windows), but with 2.20 (cross compile on Linux) it does not compile properly. The problem is that the menu text (as well as dialog box text) is supposed to be ANSI but gets compiled as Unicode -- no matter what options I give windres. At least, I cannot figure out what option to use. Is there a configure switch to be used when compiling windres on Linux which will make it work as it used to?
Created attachment 4639 [details] Original RC file, good .o and bad .o
Hi Ron, Have you tried using the --codepage=<num> switch to windres ? (I think that a value of 1252 might work. Either that or 0). Your zip file does not include the resources.h header file, so I could not run windres locally. I suspect however that this problem might be similar to the one reported in PR 11280. So possibly you could try editing winduni.h before compiling windres. Cheers Nick
Created attachment 4678 [details] Original RC file, good .o and bad .o -- second attempt (includes resource.h)
(In reply to comment #2) > Hi Ron, > > Have you tried using the --codepage=<num> switch to windres ? (I think that a > value of 1252 might work. Either that or 0). > I have indeed tried that, to no avail. What did work was reverting to windres 2.18. So something between .18 and .20 messed this up. I've resent the zip including the resource.h now. Best regards, Ron
Hi Ron, I am very sorry, but I have been unable to reproduce this problem. When I use the 2.20 version of windres I get a resource file with ANSI strings in it, not unicode. (I had to provide my own logo.bmp and icon.ico files, but I assume that this is not the reason why we are seeing different behaviours). Perhaps it is something to do with the host machines that we are using. I am using an x86 box running a 32-bit version of Fedora 12, but I would imagine that this is very similar to your own setup. Since you have a work-around of using 2.18 you may not wish to pursue this any further. But if you do, then could I ask if you could do some debugging yourself ? In particular we need to find out what the code in binutils/winduni.c is doing. Is it translating to a non-ANSI codepage, and if so, why ? The function unicode_from_ascii() would be a good place to look. Cheers Nick
Subject: New: windres compiles menus and dialogs to UNICODE not ANSI I can confirm the reported behaviour for windres 2.20.1 built cross for --target=i686-pc-mingw32 on Mac OS X 10.5.4. Next, I tried windres 2.17 and the bug disappeared. Regards, Adriaan van Os
Hmm, here rings a bell. The issue is that you are using Mac OS X. The libiconv library has here the default for UTF-16 that it uses big-endian.
Confirmed this bug still occurs with `GNU windres (GNU Binutils) 2.23.2` on OS X 10.8. Bug is now three years old, happy to help fix it if someone would give me a pointer. I fixed it by adding L in front of all my strings in the RC, however I am loath to do this because it means when compiling from Windows MingW it won't work or will require additional flags (don't know which yet).
For others who may come here, a better solution would be to use MingW64. MingW32—dare I saw—is a little unmaintained nowadays.