I have thought about localizing our messagetables, like kernel32's errorcodes.mc Now the question is: how do we do this?
We could simply add all localisations inside the current file without changing anything else in the build process. I didn't test if it works, but it should. But it would lead to huge files full of different languages and would also remove the possibility for custom selection of the languages that are compiled.
I would prefer to go the way we do with other localisation: put different .mc files in the lang subfolder. But afaik mc files don't allow inclusion of external files, so we need some build process that compiles the different mc files into rc files and include those into a main rc file. Currently our mcs are defined in makefile. This should move to the rbuild files and rbuild should compile the mc files and create the needed rc:
<module...> ... <file>foo.c</file> <file>foo.rc</file> ... <autoresource>auto.rc</autoresource>
<localization isoname="de-DE">lang/de-DE.rc</localization>
<msgtable isoname="de-DE">lang/msgtable-de-DE.mc</msgtable>
</module>
rbuild would generate <intermediate dir>\lang\msgtable-de-DE.mc.rc and auto.rc containing includes to the generated files. IMO auto.rc should be the file that is compiled, including all localizations and the unlocalized resource file.
#include "lang/de-DE.rc" #include "lang/msgtable-de-DE.mc.rc"
If I understood Fireball correctly, this is also msvc compatible. And if not, rbuild just would have to generate the files differently.
Some ideas for simplifying the rbuild definitions: Instead of <file>, <localization> and <msgtable> we could simply use <file> for unconditional compilation, <file locale="en-US"> for localized conditional compilation. And then let rbuild decide from the file extension what to do with it. resources/messagetables could automatically be included in an autogenerated rc file, without explicitly defining it in the rbuild file.
Regards, Timo
Hi Timo,
The modifications required to implement this feature on rbuild are trivial, keep in mind that mc resource files are not generated by rbuild itself, as you know makefile invokes wmc which is the tool that creates the actual resources in the intermediate folder. Creating a language folder for holding mc files, declaring them on the module rbuild file and letting rbuild generate the required makefile instructions inset of having them on Makefile as you suggested sounds good to me. It also has the advantage of conditionally exclude not desired languages with the <platformlanguage> element (see my today's commit r31154 in rbuild branch)
The only thing I don't fully agree with you is about using the <file> element for source files, resource file, localization resource files and mc files. Having them declared using specialized elements helps validating the information they contain, for example <file>lang/en-US.rc</file> is a regular resource file or a localization resource file that someone has forgotten to specify the language? No way to tell.
Regards, /Marc
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Timo Kreuzer Sent: Tuesday, December 11, 2007 3:25 PM To: ReactOS Development List Subject: [ros-dev] MESSAGETABLE localisation
I have thought about localizing our messagetables, like kernel32's errorcodes.mc Now the question is: how do we do this?
We could simply add all localisations inside the current file without changing anything else in the build process. I didn't test if it works, but it should. But it would lead to huge files full of different languages and would also remove the possibility for custom selection of the languages that are compiled.
I would prefer to go the way we do with other localisation: put different .mc files in the lang subfolder. But afaik mc files don't allow inclusion of external files, so we need some build process that compiles the different mc files into rc files and include those into a main rc file. Currently our mcs are defined in makefile. This should move to the rbuild files and rbuild should compile the mc files and create the needed rc:
<module...> ... <file>foo.c</file> <file>foo.rc</file> ... <autoresource>auto.rc</autoresource>
<localization isoname="de-DE">lang/de-DE.rc</localization>
<msgtable isoname="de-DE">lang/msgtable-de-DE.mc</msgtable>
</module>
rbuild would generate <intermediate dir>\lang\msgtable-de-DE.mc.rc and auto.rc containing includes to the generated files. IMO auto.rc should be the file that is compiled, including all localizations and the unlocalized resource file.
#include "lang/de-DE.rc" #include "lang/msgtable-de-DE.mc.rc"
If I understood Fireball correctly, this is also msvc compatible. And if not, rbuild just would have to generate the files differently.
Some ideas for simplifying the rbuild definitions: Instead of <file>, <localization> and <msgtable> we could simply use <file> for unconditional compilation, <file locale="en-US"> for localized conditional compilation. And then let rbuild decide from the file extension what to do with it. resources/messagetables could automatically be included in an autogenerated rc file, without explicitly defining it in the rbuild file.
Regards, Timo
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi Marc,
ReactOS desperately needs a tool which builds all the DLLs, then looks at the filesize, chooses a lower-bound base address (such as 0x60000000) and creates a baseadress.xml/.cfg with the right addresses for each DLL.
There are then two choices:
- You generate this .xml once on your computer, and commit the new .cfg - People run this code at every build, the .cfg gets generated, and all the DLLs re-linked at the new address (this should take less than 30 seconds).
The DLL relocation hell in ReactOS has gotten too bad and manually choosing base addresses which seem to work doesn't work anymore.
-- Best regards, Alex Ionescu
Hi Alex,
Let me see if I understood this correctly. The problem is not really on manually choosing the base address, the problem is that module's "baseaddress" attribute is optional, even when the module is of type "win32dll", if this attribute is empty rbuild sets a common default base address (0x10000000 for win32 dll's).
AFAIK we are using the same base address that the equivalent component has on windows so auto generating it using any sort of tool is not really an option.
In my rbuild branch I introduced the new element "baseaddress", despite it's only a specialized type of "property" it presents some advantages, first of all it gives *meaning* to the information it contains and also allows more complex validations as we known what to expect.
This "baseaddres" element has for now and identical syntax to "property" for example <baseadress name="BASADRESS_JOY" value="0x589b0000" /> so currently to use the value it contains module's "basaddress" attribute must explicitly reference it by name. I could extend it support an additional attribute "dllname" so rbuild could try to auto reference it before falling back to default baseadress in case no value has been specified and no baseaddress could be resolved by module's target name (module.dll). It would act as a base addresses index, we could keep adding correct baseaddress even for not yet existing dlls on reactos. When a module that outputs that dll is created rbuild will link the image to the right address without developer intervention.
Sound good to you?
/Marc
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: Saturday, December 15, 2007 6:26 PM To: ReactOS Development List Subject: [ros-dev] DLL Base Addresses (For Marc)
Hi Marc,
ReactOS desperately needs a tool which builds all the DLLs, then looks at the filesize, chooses a lower-bound base address (such as 0x60000000) and creates a baseadress.xml/.cfg with the right addresses for each DLL.
There are then two choices:
- You generate this .xml once on your computer, and commit the new .cfg - People run this code at every build, the .cfg gets generated, and all the DLLs re-linked at the new address (this should take less than 30 seconds).
The DLL relocation hell in ReactOS has gotten too bad and manually choosing base addresses which seem to work doesn't work anymore.
-- Best regards, Alex Ionescu
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Alex Ionescu -
Marc Piulachs -
Timo Kreuzer