When an application is loaded for execution, the resource elements are not loaded. Instead, resources, such as dialog boxes and menus, are loaded only on demand, as required. When a resource is no longer needed, it is discarded. The advantage of loading resources on demand is simple: Memory is expended only for currently operating elements. Memory is not used for storage of elements that may or may not be needed.
For example, one version of a solitaire program (Sol.EXE) contains 74 bitmaps (52 for the card faces alone), one menu, five dialog boxes, one accelerator table, one icon, and one custom resource type—a fairly small load as resource elements go.
In contrast, another application might contain only one resource and the application’s icon, and then use a series of .DLL files. These .DLL files might contain hundreds of bitmap images, dozens of menus and dialog boxes, multiple accelerator key sets (for different circumstances), a hundred separate cursors, dozens of additional icons, and a huge string table.
In both cases, if these massive assortments of resources needed to be loaded into memory immediately on execution of the application, your system memory would quickly become overloaded. And only a small portion of these resources might actually be used at any time. Instead, under Windows, because the system loads resources only on demand (when they are needed), memory remains free for other uses.
Another advantage to the Windows approach is that you can edit application resources without needing to recompile the files. While the usual practice is for programmers to edit their own resource files before compiling and linking, they can now edit executable program resources.
NOTE
When executables are opened for resource editing, the original resource names do not appear. Instead, all resources are labeled by their identifier values.
Keep in mind, however, that application resources define only the appearance and organization of the resources, not their functional characteristics. By using a resource editor to edit a dialog box, for example, you can change the arrangement or appearance of that dialog box, but you cannot alter how the application responds to the dialog box controls. This means that you can make only cosmetic changes by editing resource elements. If you need to make functional changes, you must revise the application’s source code and then recompile it.