Win32 dynamic connection database base address Reset Technology

Theory

To load the dynamic link library operating system, you must complete the following steps:

1. Locate the executable file of the dynamic link library on the disk.
2. Check the list of dynamic link libraries that have been loaded into the application address space to determine whether the dynamic link library has been loaded.
3. Allocate resident memory for the dynamic link library and map the binary file of the Dynamic Link Library to the memory (in Windows NT, The ing spans the segment object ).
4. To make the dynamic link library run properly, execute a series of necessary operations (such as parsing the corrections made in the dynamic link library ).

Different parameters determine the loading time of the dynamic link library. The following lists the factors that need to be considered. In fact, some factors may also affect the loading time of the Dynamic Link Library:

• Underlying Software and Hardware: the speed and operating system of the computer.
• Status of the current system and application: System closeness in the virtual memory, and whether the dynamic link library can be loaded in the preferred base address.
• Dynamic Link Library itself: the size of the Dynamic Link Library itself, and the location of the dynamic link library that needs to be corrected (combined with both ), whether the dynamic link library is implicitly linked to another dynamic link library that also needs to be loaded.

The above analysis shows that resetting the base address of a dynamic link library is by no means the only factor affecting the loading time of the dynamic link library. In this article, the author uses a lot of data to explain the variation scope of the loading time of the Dynamic Link Library and the extent to which the application may affect the loading time.

Readers should note that resetting the base address of a Dynamic Linked Library may not only greatly increase the loading time, but also increase the overhead of pagefile. To load a dynamic link library, you must create a section object. The section object is an adjacent section in the memory supported by the executable file of the dynamic link library. Once a page of the dynamic link library is removed from the application working set, the next time you access this page, the operating system will reload this page from the dynamic link library executable file.

Of course, this policy does not work when the dynamic link library resets the base address, mainly because the page containing the relocated address is different from the corresponding page in the executable file ing of the dynamic link library. Therefore, when an executable file is loaded, the operating system attempts to correct the address and copies the corresponding page (because the segment is opened through the copy_on_write flag ). All the modifications made in the copy operation will be remembered by the operating system. From now on, the page will be swapped in and out in the system page file, instead of page switching in the executable image.

Using this mechanism, there are two potential performance hits: First, each page containing the address to be relocated occupies a page of system page files (the result is, reduces the number of virtual memory available for all applications. In addition, because the operating system performs the first correction operation on the dynamic link library page, the new page must be allocated from the page file, and copy the entire page.

Although the efficiency of scanning dynamic link library relocation segments and memory correction algorithms is high, the execution of correction operations will increase the loading time of the dynamic link library. (The complexity of cross-segment operations is the linear function that requires fixing the number of addresses .)

Address correction

A frequently asked question about resetting the base address of the dynamic link library is: "What does address correction mean? Can programmers adjust the code to reduce the address correction in executable programs ?" The answer to these two questions is that it depends to a large extent on the platform where the executable program is built. In this article, we will restrict the platform to Intel 386, 486, and Pentium processors and discuss the corresponding executable programs. (Note: For executable programs created for other platforms, the corresponding address repair concepts are different from those discussed in this article .)

On the 386, 486, or Pentium processor, either of the two situations may lead to an address being marked as "relocable": a static object (static objects ), another scenario is absolute jump (absolute jumps ).

First, if the dynamic link library references a static object, the absolute address of the object will be used (assuming that the dynamic link library is loaded into the preferred address ). For example, in the following code snippet:

Lpstr lpname = "name ";

The loader of the dynamic link library will allocate the "name" string to the Data Segment of the dynamic link library, and fill in the Start address of the string to the position corresponding to the lpname variable. If the "name" string must be relocated because the DLL cannot be loaded to the base address, the lpname must be adjusted accordingly. Note: In this case, the address of each variable that references lpname in the code segment must also be corrected accordingly.

Objects that can be relocated include text strings (for example, the "name" string in the preceding example), global or static data of any type, and static allocated C ++ objects. It should be noted that, especially in C ++, there may be many cross indexes from one static object to another. Uninitialized data does not need to modify the address during the relocation process, but the index pointing to the uninitialized static data requires address correction.

In i386 executable code, another type of item that can be relocated is absolute jump and function call, including system function call. Note that it is difficult for program developers to modify program code to avoid address relocation. The only way to do this is to reduce the number of static data allocated. To reduce the size of static allocation data, one way is to avoid using the name for resource indexing, instead of using coordinates for resource indexing (because, every name explicitly used by the programmer in the code will automatically become a relocable item ).

However, the author does not recommend that program developers develop dynamic link library code for the special purpose of reducing loading time, unless there are two situations: (1) the data of static objects can be greatly reduced. (2) When programmers program in this way, it does not affect the factors that need to be considered in other programming.

In addition, program developers can also reduce the loading time through simple optimization methods. For example, you can centralize all data that can be located on several pages. Obviously, if the dynamic link library needs to reset the base address, each page contains two pages of a relocation item, which must be supported by page files. If all relocation items appear on the same page, only one page needs to be supported by a page file, so only one page is affected. When necessary, you can use the Pragma (data_seg, Data Segment) directive to ensure that as many relocated items as possible are allocated to as few pages as possible.