2. General Information
The resource file is created by the resource compiler (RC) while parsing the resource script file (.RC) and including any other resource data files (for example, .ICO, .CUR, .BMP, .FNT). The resource file contains all information necessary to build the resource table in the executable image. The main purpose of the resource file is to speed the edit-compile-link cycle by not always forcing resources to be recompiled.
There are currently about a dozen predefined resource types. These include Menus, Dialogs, Accelerators, Strings, Icons, Cursors, Bitmaps, Fonts, and Version. These resources are used by the Windows system to define the appearance of the application window. The resource script allows the application writer to represent these features in an easily editable form. Other type ranges are reserved for use by the application for application-specific data. No attempt is made by the resource compiler to modify this user-defined data from 16-bit to 32-bit format.
The executable image file for Win32 is not a segmented image. In the 16-bit executable image file, each resource was placed into a separate segment in the image file. The Win32 image file places all resources into a single object or section. The Win32 image file also provides a binary-sorted resource table that allows fast lookup of a particular resource, rather than a table that must be searched linearly, as in the 16-bit image file. Because this Win32 image file format is more complex than the Windows 16 format, making it harder to update directly, the Win32 API provides methods of modifying the resource data directly.
The CVTRES conversion utility that converts the resource file into a COFF object creates the resource table. This table contains two or three directories, indexed by Type, Name, and Language, in that order. The Language directory is optional. The Type and Name directories consist of two parts: the part dedicated to resources whose types or names are represented by strings, and those represented by ordinal WORD values. Because the use of strings as resource type and name identifiers takes considerably more room than ordinal identifiers, Microsoft recommends that they not be used.
Note that, as all strings in a resource file (including the strings used to identify the type and name of resources) are Unicode, the corresponding strings in the program that are being passed to LoadBitmap, and so on, must also be Unicode (only if the application is using the Unicode set of APIs rather than the ASCII set). This is facilitated by use of the TEXT macro provided in WINNT.H.
The third level, language, provides the capability for the application developer to ship a single executable image that supports more than one language. For instance, one image providing French, French-Canadian, and French-Belgian could easily be shipped in one image file. An application could also be shipped with support for all languages supported by the Unicode standard, although this would probably make the image very large.