Folks,
I've just discovered (DUH!) another free resource compiler:
http://www.redhat.com/docs/manuals/gnupro/GNUPro-Toolkit-98r2/5_ut/c_Usingbi...
This one is part of binutils. Now, like any good hacker, I hate such code duplication. Granted, I haven't looked through the code of windres, so I can't say if it's any good.
However, here are some points to ponder: -- all Win32 free software projects out there use windres, not wrc -- for this reason, it is like it's more generic / better maintained -- do we want eventually to phase one of them out? -- their command line arguments are incompatible. This causes problems when trying to build portable Makefiles. Should we try to be command line compatible with windres, so we are a drop in replacement (for the .rc/.res -> .o conversion)?
Any windres experiences? Comments?
"Dimitrie O. Paun" dpaun@rogers.com wrote:
However, here are some points to ponder: -- all Win32 free software projects out there use windres, not wrc -- for this reason, it is like it's more generic / better maintained -- do we want eventually to phase one of them out? -- their command line arguments are incompatible. This causes problems when trying to build portable Makefiles. Should we try to be command line compatible with windres, so we are a drop in replacement (for the .rc/.res -> .o conversion)?
Any windres experiences? Comments?
Here are some windres limitations I'm aware of:
1. it knows nothing about unicode and therefore can't correctly compile resources with languages apart from English. 2. at least an year ago it generated wrongly aligned RCDATA sections, which affects all winmm resources in Wine. 3. it can't compile 16-bit resources, which is a critical feature for Wine.
#1 renders windres completely unusable for us.
In the past there were some patches for windres from the ReactOS guys, but AFAIK nothing related to the above bugs.
.res -> .o conversion (which windres is able to do) is very valueable for all Windows based projects. WRC is not able to do it.
WRC was made to be somewhat compatible with Microsoft resource compiler in using command line switches. That's not the case for windres.
On November 17, 2002 11:56 pm, Dmitry Timoshkov wrote:
- it knows nothing about unicode and therefore can't correctly compile resources with languages apart from English.
Putty is using Unicode with windres, so I guess this is fixed.
- at least an year ago it generated wrongly aligned RCDATA sections, which affects all winmm resources in Wine
Doesn't sound like a big thing to implement, no?
- it can't compile 16-bit resources, which is a critical feature for Wine.
Hm, this may be tough to support in windres, as there are no users for this.
.res -> .o conversion (which windres is able to do) is very valueable for all Windows based projects. WRC is not able to do it.
I was thinking maybe we can add it in... Maybe a simple hack, such as calling as internally.
WRC was made to be somewhat compatible with Microsoft resource compiler in using command line switches. That's not the case for windres.
Which is cool. But windres support long options, and maybe we can add a compatible set too, so we can have a single target in makefiles:
%.o : %.rc $(RC) ....
This way, people can add tests to their configure scripts to just use wrc or windres, depending on availability.
What do people think?
"Dimitrie O. Paun" dpaun@rogers.com wrote:
- it knows nothing about unicode and therefore can't correctly compile resources with languages apart from English.
Putty is using Unicode with windres, so I guess this is fixed.
According to CVS, windres has a kludge for some kind of unicode support: it uses MultiByteToWideChar(CP_ACP) to convert resource strings to unicode if compiled under Win32 platform. But there is no support for multiple languages/ code pages which Wine need.
- at least an year ago it generated wrongly aligned RCDATA sections, which affects all winmm resources in Wine
Doesn't sound like a big thing to implement, no?
Sure, this is not a big thing. But why we should bother? We have a working and maintained resource compiler in the Wine tree.
- it can't compile 16-bit resources, which is a critical feature for Wine.
Hm, this may be tough to support in windres, as there are no users for this.
.res -> .o conversion (which windres is able to do) is very valueable for all Windows based projects. WRC is not able to do it.
I was thinking maybe we can add it in... Maybe a simple hack, such as calling as internally.
I'm afaraid that's not enough. What windres does, is creating .rsrc coff section which ld with compiled in PE support can understand and link.
WRC was made to be somewhat compatible with Microsoft resource compiler in using command line switches. That's not the case for windres.
Which is cool. But windres support long options, and maybe we can add a compatible set too, so we can have a single target in makefiles:
%.o : %.rc $(RC) ....
Sure, adding compatible with windres long options is feasible, but short options very likely will conflict.
In the past there were some patches for windres from the ReactOS guys, but AFAIK nothing related to the above bugs.
I dont know if you guys cross-compile to test wine/mingw or not but Alexandre patched the build system so all wrc resources get feed to wrc then windres for linking when building under Windows. I am not 100% sure about the bugs in windres but I know that the format of wrc resources were a issue untill this patch. I have never had a problem building a dll or winelib app and using windres if the resource is feed to wrc first. These bugs are non-issues except for us (ReactOS) when we start to import the WINE dlls and applications with resources. We will have to change our build system to incorporate wrc before linking to windress if we want to minimize forking of code.
Thanks Steven
__________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com
-
Dimitrie O. Paun -
Dmitry Timoshkov -
Steven Edwards