[RFC] wrc & windres
Dimitrie O. Paun
dpaun at rogers.com
Thu Dec 5 01:11:45 CST 2002
As we discussed here a few weeks ago, there is good reason
to have a windres compatible mode for wrc. Needless to say,
this will greatly ease porting apps that use windres to
Winelib. More information about the issues at hand can be
found in this thread:
These messages in particular deal with this problem:
That being said, what would it take to (1) keep the current wrc
behavior, and (2) make it compatible with windres?
First, windres supports any conversions between .rc, .res, .o
files, whereas wrc supports only .rc -> .res. It would be
interesting (from the Winelib point of view) to also support
.rc and .res -> .o. The other transformations supported by
windres (.o -> .res -> .rc) are not as interesting, as they
are not used in the build process.
With that in mind, what do we need to do to have said compatibility?
Well there are two things:
1. Support windres command line options
2. Add conversion of .rc and .res to .o
I will treat each of these below.
Command line compatibility
Luckily, there is only one (seldom used) option that conflicts: -I.
Moreover, it has a long format name in windres as well, which can be
used instead. In other words, it should be very simple to add support
for the windres options to wrc (most of them will just get ignored).
In other words we can support windres's options while keeping full
backwords compatibility. Having this compatibility makes sense as
long as we support the conversion to .o files as well. Assuming we
can do that, I would say this is something we should have.
Conversion to .o files
As Alexandre pointed out in here:
generating .o files in proper format is non-trivial. And since
I'm willing to do the work, there's no chance I'm going to propose
something difficult to implement! :)
What I have in mind is quite simple: store the .res file, as a byte
array, in a .wine.resources ELF section, and have winebuild pick it
up from there (as an alternative to getting it directly from the
.res file, so current behavior is conserved).
With these two changes, we eliminate the biggest nastiness of getting
apps compiled with Winelib. The modification will typically be:
Moreover, the solution is:
o Simple to implement
o Fully backwards compatible with current Wine practice
o Fully compatible with Win32 apps using the MinGW toolchain
o Supports multiple resource files, etc.
So now the big question: Alexandre, are patches that implement these
Sorry for the long message, and thanks for reading this far.
More information about the wine-devel