Hi folks,
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: http://www.winehq.com/hypermail/wine-devel/2002/11/index.html#1518 These messages in particular deal with this problem: http://www.winehq.com/hypermail/wine-devel/2002/11/1546.html http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html http://www.winehq.com/hypermail/wine-devel/2002/11/1551.html http://www.winehq.com/hypermail/wine-devel/2002/11/1552.html http://www.winehq.com/hypermail/wine-devel/2002/11/1555.html
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: http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html 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: -WINDRES=windres +WINDRES=wrc
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 ideas acceptable?
Sorry for the long message, and thanks for reading this far.
"Dimitrie O. Paun" dpaun@rogers.com wrote:
Conversion to .o files
As Alexandre pointed out in here: http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html 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).
I have no objections to the most things, they look quite reasonable to me. Only one small suggestion: instead of .wine.resources section name use simple .rsrc, which should not conflict with anything else in the ELF world and is just a native name for resources in the Win32 world.
On December 5, 2002 04:33 am, Dmitry Timoshkov wrote:
Only one small suggestion: instead of .wine.resources section name use simple .rsrc, which should not conflict with anything else in the ELF world and is just a native name for resources in the Win32 world.
Sure, this is no problem. I was thinking of a wine specific name because we don't put the resources in there as the native Win32 does, it's a Wine specific thing. Maybe in the future we will want to stick stuff in .o file in native format, and then we would use .rsrc, without conflicting with this method (and thus maintaining backwards compatibility).
"Dimitrie O. Paun" dpaun@rogers.com writes:
So now the big question: Alexandre, are patches that implement these ideas acceptable?
If you can make it clean enough sure; but I'm not convinced this is possible, especially if you are playing with ELF sections. If it's going to be an awful hack then I much prefer the approach of creating a dummy .o and handling that in the wrapper tool. It's still ugly but at least it's much less complexity to maintain for such an IMO minor feature.
On December 5, 2002 11:19 am, Alexandre Julliard wrote:
If you can make it clean enough sure; but I'm not convinced this is possible, especially if you are playing with ELF sections. If it's
To be honest, I've never worked directly with ELF section, it was just an idea to store that info somewhere.
going to be an awful hack then I much prefer the approach of creating a dummy .o and handling that in the wrapper tool.
Well, that's the idea, really. But I have to find a way to mark the special .o files somehow. I don't think just touching them works, because of possible separate source and build trees. At a minimum I have to store the .res/.rc file name in it, and I figured if I do that, I might as well store the .res content. But if you have a better suggestion on how to store some info in a .o file that we can than easily detect in the winewrap tool, I'm all ears.
BTW, storing the .res content in the .o file has the small benefit that resource compilation happens at the expected place in the build process, but I guess we can defer it to winewrap, no problem.
It's still ugly but at least it's much less complexity to maintain for such an IMO minor feature.
It does look like a minor feature, but it's probably less work than to mess around with the Makefiles of say Mozilla. If this is ugly, the alternative is plain nasty. :)
"Dimitrie O. Paun" dpaun@rogers.com writes:
Well, that's the idea, really. But I have to find a way to mark the special .o files somehow. I don't think just touching them works, because of possible separate source and build trees.
I think it would work, the .res is going to be in the build tree too. You could also create a symlink if you are concerned about that. But maybe a better approach would be to simply output the .res into a .o and have winebuild check the file header to recognize when an object file is a .res in disguise; this way you don't need an intermediate .res.
BTW, storing the .res content in the .o file has the small benefit that resource compilation happens at the expected place in the build process, but I guess we can defer it to winewrap, no problem.
Not sure what you mean here; the .res is already compiled anyway.
On December 5, 2002 12:07 pm, Alexandre Julliard wrote:
But maybe a better approach would be to simply output the .res into a .o and have winebuild check the file header to recognize when an object file is a .res in disguise; this way you don't need an intermediate .res.
I thought about that too, but I was a bit worried to bend things this much. But it's certainly simple to implement, and avoids a bunch of problems. Moreover, on the outside chance someone tries to use the .o files as object file, ld will complain about that, so there's no danger to it. I'll proceed this way.
BTW, storing the .res content in the .o file has the small benefit that resource compilation happens at the expected place in the build process, but I guess we can defer it to winewrap, no problem.
Not sure what you mean here; the .res is already compiled anyway.
Indeed, if we go by the above. But if I were to simply touch myfile.o when myfile.rc was given to wrc, then in winewrap I would have had the .rc -> .res conversion. But nevermind, this is no longer an issue.
-
Alexandre Julliard -
Dimitrie O. Paun -
Dmitry Timoshkov