Home Overview Localization of PE32/PE32+ files
Localization of PE32/PE32+ files PDF Print E-mail
Article Index
Localization of PE32/PE32+ files
Resources
Hard-coded strings
Dialog resources
Menu resources
Localization methods
Resource library
Localized files
Selecting a localization method
All Pages

PE32/PE32+ files

PE32/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

PropertyInspector_smallResources in PE files are a special data structure that represents itself a hierarchical list of resource types, resources, languages and data itself.

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_::

  • RT_CURSOR[#1] - Cursor images
  • RT_BITMAP[#2] - Raster images
  • RT_ICON[#3] - Icon images
  • RT_MENU[#4] - Menus
  • RT_DIALOG[#5] - Dialogs
  • RT_STRING[#6] - Strings, Unicode
  • RT_FONTDIR[#7] - Font directory
  • RT_FONT[#8] - Fonts
  • RT_ACCELERATOR[#9] - Accelerators (combinations of hot keys)
  • RT_RCDATA[#10] - Various data
  • RT_MESSAGETABLE[#11] - Strings
  • RT_GROUP_CURSOR[#12] - Cursor group
  • RT_GROUP_ICON[#14] - Icon groups
  • RT_VERSION[#16] - Version
  • RT_DLGINCLUDE[#17] - Names of header files for dialogs (*.h). They are used by the compiler.
  • RT_PLUGPLAY[#19] - Type of data is determined by application
  • RT_VXD[#20]
  • RT_ANICURSOR[#21] - Animated cursors
  • RT_ANIICON[#22] - Animated icons
  • RT_HTML[#23] - HTML pages
  • RT_MANIFEST[#24] - Manifest of Windows XP build
  • RT_DLGINIT[#240] - Strings, used for initiating some controls in dialogs
  • RT_TOOLBAR[#241] - Configuration of toolbars
Language code in PE resources is a double-byte digit. The lower 10 bits are a primary language ID, the remaining 6 bits are a secondary language ID. Language codes can be viewed in the ID column in the list of supported languages.

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
load resources, name or resource index. The functions do not accept the language code. The language is selected by the operating system. Firstly, it searches for the resource with the language code that matches the language code of the thread, from which the function is called. If this resource is not found, the program searches for the resource, whose main part of the language code matches the main part of the language thread code (if there are several resources with the required value of the main part, the program returns the resource that was found first). If this search fails, then the program searches for the resource with the code of a "neutral language” (code value 0).


Hard-coded strings

If 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.

Hard-coded string settings

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:

  • Pascal - strings that have the “string” type in Delphi
  • Pascal Wide - strings that have the “widestring” type in Delphi
  • Pascal Short - strings that have the “shortstring” in Delphi
  • UNICODE - strings in UNICODE (2 bytes per character) that end with a null
  • ASCII - strings in ANSI (1 byte per character) that end with a null

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 resources

In PE files, dialog resources have this type: RT_DIALOG[#5]. To edit dialogs, Radialix 2 offers a visual designer.

DialogDesigner_small

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.

DialogInspector_smallAs you do editing, the designer can resize and snap controls to the guide lines or grid (“Use snap lines” and “Snap to grid” options in the context menu of the designer). Similar commands for a group of selected elements are available in the context menu of the designer.

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 resources

The 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.

MenuDesigner_small


Localization methods

  • Resource Library - This is a file of a dynamically loaded resource library that contains resources of one language. A separate file is created for each project file or language. As a library prototype, you can use an image file built into Radialix 2 or an external file.
  • Multilingual Resource Language – This is a multilingual file of a dynamically loaded resource library. One file is created for each project file. This file contains resources for all languages of a project. As a prototype of a library, you can use an image file built into Radialix 2, or an external file.
  • Localized File - This is a copy of an original file with edited resources. Resources labeled as Ignore or Read-only are saved in the original form. A separate file is created for each file of a project or language. This file type also enables you to localize hard-coded strings.
  • Multilingual Resource File – This is a copy of the original file with resources for several languages, resources labeled as Ignore remain in the original form. A separate file is created for each file of the project.

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.

Win32Targets_small


Resource library

To 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 files

A 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:

  1. The size of data in localized resources exceeds the size of data in original resources and there is no opportunity to relocate data located in a PE file after resource data. As a result, a new section is added to the end of a file, and localized resources are saved to this section. References to resources are corrected according to the new location of this data (If the size of localized resources is smaller than the size of original resources, the empty space if filled with nulls).
  2. The translation of one or more relocated hard-coded strings exceeds the size of an original string. A new section with the attribute of initiated data is added to the end of file; the translated string is relocated to this section, references to the string are corrected.

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 method

The 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.

Advantages

Disadvantages

Resource Library

1. Small size

2. Installation package can contain a library only for required languages, which reduces its size.

3. Easy to add support for dynamic switching of interface language.

4.Automatic loading of a resource library based on the current language when a VCL library is used (Delphi/C++Builder), utomatic loading of resources from .NET assemblies (.NET applications, forms labeled as “Localizable”), support by other libraries and compilers.

1.No support for localization of hard-coded strings.

Multilingual resource library

1. Automatic selection of resources for the current language by OS when standard functions are used in the application.

1.  No support for localization of hard-coded strings.

Localized file

1. Support for localization of hard-coded strings.

2.  Translation is contained inside one file, which ensures reliability of the application.

1. Large size, larger than the original file.

2. No support for dynamic switching of language.

Multilingual localized file

Single file. No need to distribute additional files, which increases reliability of the application.

2. Automatic selection of resources for the current language by OS when standard functions are used in the application.

1. No support for localization of hard-coded strings.

2. Difficult to realize dynamic switching of language.

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
resource library, but there are some hard-coded strings that need to be localized, the only localization method is to create a localized file.