CODEWITHSUNDEEP
windowsdllexeportable-executablecoff
user2649681
user2649681

Reputation: 838

How does Windows find where to dynamically link functions at load

I've been trying to learn about the PE file structure, and I compiled the following short program to examine the output:

#include <stdio.h>

int get_5() {
    return 5;
}

int main() {
    int five = get_5();
    fputc(five, stdout);
    return five;
}

This uses the fputc function, which needs to be linked in from a .dll file. I compiled this in MSYS using gcc -o program.exe program.c.

When I look in the resulting executable's .idata section, it shows that it imports fputc from msvcrt.dll. It includes a name hint that I think is used to find where to link it within the .dll.

My question, however, is how does Windows then use this information to find where in the .dll to take the function? When I look inside msvcrt.dll, it does not contain a .edata section, which I thought is where information for exporting symbols is located. If there were an export table, I would assume the program loader looks through the ordinal and/or name pointer tables in the export section to get a pointer to the requested function. So, without an export table, how do the hint and name help to find the location of the function?

Upvotes: 1

Views: 125

Answers (1)

user2649681
user2649681

Reputation: 838

I think I found an explanation. While the .dll's do not contain a .edata section, they contain an image data directory entry for an export table in their optional header, which points to data in the .rdata section that is in the same format as a .edata section would have. Though I am still unclear on when a file would have an actual .edata section and would it would just have export data in .rdata. I imagine the same is true for imports, as well.

Upvotes: 0

Related Questions