| Localization of PE32/PE32+ files |
|
|
|
PE32/PE32+ filesPE32/PE32+ files are executable files (exe, dll, ocx, cpl, scr, etc.) of Windows OS (Windows 98, NT, 2000, XP, Vista, CE, Mobile, etc.). The PE32 format stands for Portable Executable 32-bit, while PE32+ is Portable Executable 64-bit format. These files are referred to as PE files below. PE files consist of sections, each of which may contain data of different types. Standard types of data are import data, export data, relocation tables, resources, thread data, etc. Usually this data is contained in separate sections but it is also possible to place data of different types in a single section. The application code and data for it can be placed randomly – in one section, in different sections or they can be allocated to several sections. According to PE32/PE32+ specifications, the maximal count of sections is 65535, but usually PE files contain no more than 10. Each section has a name and attributes. The name of a section can be random. Often, the name reflects the type of data in a section: .text, .data, .rsrc, DATA. CODE, idata. Section attributes are important as they characterize data properties, such as executable code, initiated data, etc. The standard method to localize PE32/PE32+ files is to allocate all language-dependable data to application resources and embed into the application the code that will load resources, depending on the current or user selected language. Localized resources can be placed to a localized file itself, or a separate DLL library, which is usually referred to as a resource library. This library, as a rule, does not contain any useful code and used only to store resources. A file may contain resources for several languages. This file is called multilingual. Another frequently used method of localization is to use text files with strings that need to be localized. Usually this file has INI or XML format and contains data of only one language. The localized application contains the code that loads the required language file and gets data from it. Radialix 2 does not support creation of text language files from PE files but supports localization of INI files, which allows creating new language INI files from the existing ones. The localization method for PE files is mainly determined by the author of the application, type of the used libraries and programming environment. The application must contain the code that ensures loading data from resources, or from external files. If this code is not realized, or realized partially, localization is possible only by creating a localized file – a copy of the original file with modified resources and creation of multilingual files is impossible. Resources
Types of resources and resources in PE files are identified by name or index. The method of identification is determined by the value of the 4-byte field. If the value is within the range from 1 to 65535 (0 – invalid value), it is an index value and identification is done by index. However if the value in the field exceeds 65535, then it is a reference to a string, which is a name and types and resource in PE files are identified by name. The initial values of resource type indexes are reserved and used for standard types of resources. For the sake of convenience, names of such types are automatically set according to the conventional constants with the prefix RT_::
LoadString, LoadBitmap, LoadIcon, LoadCursor, LoadAccelerators, LoadMenu, FindResource, LoadResurce functions are used to load data from resources inside an application (more detailed information about these functions can be found in MSDN). These functions accept the module descriptor as parameters, and the module descriptor is used to Hard-coded stringsIf an application does not support localization with the help of resources or supports it partially, then some strings that need to be localized can be in the code, or code data of a PE file. These strings are called hard-coded. You can configure the settings related to extraction of hard-coded strings in the File Properties dialog on the Hardcoded Strings tab. When you add a new PE file to the project, extraction of hard-coded strings is disabled by default. You can enable or disable extraction of strings as you start editing resources. Modified settings take effect as soon as you have updated resources. Radialix will suggest you to update resources when you close the File Properties dialog. The program extracts the following types of strings:
As the program searches for hard-coded strings, it can find data that resembles strings but not real strings. Filters can help you reduce the number of false strings. Filter settings can be configured on the Hard-coded Strings tab in the File Properties dialog. Radialix 2 can also find strings that must not be edited because they influence the performance of an application. Therefore the status of hard-coded strings is set to "Read-only" after extraction to avoid undesirable changes. To make strings editable, you need to select the required string and remove the "Read-only" status. You must decide yourself whether to edit a string or not, and after creating localized files, it is necessary to make sure the application runs well. Extracted strings are placed to relevant sections in the ~HARDCODED resource type. Dialog resourcesIn PE files, dialog resources have this type: RT_DIALOG[#5]. To edit dialogs, Radialix 2 offers a visual designer. The designer allows you to use the mouse to move and resize controls, as well as resize a dialog itself. You can select and edit more than one control. To do so, simply make a selection with the mouse, or hold down CTRL when you make a click.
The dialog designer also allows the user to insert user text (static control). To do so, go to Control>Insert... Elements added to the project by the user are labeled as Added by user (U). You can delete these elements from the context menu of the designer. All properties of the controls, as well as the dialog itself are available in the properties inspector. On top of the inspector, there is a drop-down list, which contains the list of all dialog controls. This list is very convenient when the user cannot select the required element in the designer (for example, if a control is not displayed due to incorrect coordinates). Menu resourcesThe menu designer displays the structure of a menu and allows the user to select menu items (RT_MENU[#4] resources). You can edit menu items in the table editor. Submenu items open automatically on selecting data in the table editor. Menu items cannot be added. Localization methods
The type of the created file and its name can be changed anytime after creating the project. You can do this on the Target Settings tab in the File Properties dialog. Resource libraryTo localize using resource libraries, the user is required to create a separate library for each translation language. The name of a localized file is used for the name of a resource library file, and the extension is set based on the letter code of a language in Windows (en, de, ru, etc.). The localized program must have a field to store a resource module descriptor. This field is used as a parameter in all above mentioned functions. In the beginning, this field is initiated by the descriptor value of the executable module itself. Then, the required resource library is loaded if it is necessary to use localized resources. The extension of the library name is made by the language code of the current thread, or language code, defined by the user with the help of the “GetLocaleInfo” function. Once the library has been loaded, the descriptor of the loaded library is saved to the descriptor field. After this, all functions will get resources from the new module. This method of loading localized Win32/MFC resources is considered typical. Therefore when you localize such applications, it is recommended to follow the rule below: Resource libraries must contain all resources of the original file. Otherwise, the resource may not be found and the localized application will run incorrectly (not a single resource type or resource should have the status Ignore). Localization using resource libraries is perfect to make a dynamic switch of the application language during its run-time (an example of this application is available in the demo samples). If the user, for example, makes a language switch using multilingual files, then it’ll be necessary to use the functions that get the language code, which is not always convenient. To switch languages, the loaded resource library must be unloaded, a new library must be loaded and the descriptor field is initiated by the descriptor value of the loaded resource module. The original module contains language resources, used by the application author. As a rule, it is English (English is recommended as it is easier to find a translator from English to any other language than vice versa). To switch to the language of the original module, it is necessary to make the descriptor field of the resource module equal to the descriptor value of the original module, then the resource library can be unloaded. If the application contains several modules (for example, an executable file and several DLLs), it is necessary to create resource libraries for each module and the application must have a separate resource descriptor field for each module. The fields and descriptors of original modules can be organized into a list for convenience. PE files, made with the VCL library (Delphi/C++Builder), support automatic loading of the resource library for the current interface language on application launch. There is no need to add any extra code to the application to enable this feature. Also, there is no need to save all resources to the library as VCL searches for resources in the executable module. Typically .NET applications can also load resource assemblies on application launch (a resource assembly is a PE file, an analog of a resource library). Resource assemblies are loaded on application launch for forms, which are labeled as Localizable. Localized filesA localized file is a copy of the original PE file with edited resources. This file can contain resources in several languages (multilingual file). Creation of localized files allows the user to localize hard-coded strings. However the file can contain data of only one language. The name of a localized PE file is the same as the name of an original file. You can add extra sections to a PE file. It occurs in the following cases:
As the program creates a PE file, it can update the field of the controlled sum, which is contained within the structure inside a file. The structure is called “Optional Header”. This field is updated if its value in the original file was not equal to 0. Selecting a localization methodThe author chooses the localization method for PE32/PE32+ applications himself.All methods have their advantages and disadvantages. Therefore there is no definite answer as to which method to choose.
If you are not the author of the localized application and do not know the localization method it supports, we recommend you to build a resource library that meets the criteria described in the "Resource Library" section. As compared to localized files, the benefit of resource libraries lies in their smaller size. If the localized application does not load a resource library, you can localize the application by creating a localized file – a copy of the original file but with modified resources. If the localized application loads a |