Reader Tom brought up the interesting point that ordinal-based imports are slightly faster than name-based, though not by much. But if even that tiny fraction of a percentage bothers you, you can still get the benefits of ordinal-based imports while still being name-based.
People are more familiar with the first half of the “rebase and bind” duo than the second. But it’s binding that speeds up import table resolution. When a DLL is “bound” to another DLL, information about the target DLL is cached in the original DLL. Specifically, the timestamp of the target (so that the loader can detect whether the cache is valid), the ordinal corresponding to the name (the “hint”), and the address of the ultimate function. For example, if I had a DLL that linked to
kernel32!LocalAlloc the entry in the DLL would go something like this:
“Hello. I would like to link to these functions in
kernel32. Oh, and by the way, all the hints I’m about to give you are based on the Aug 04 00:56:36 2004 version of
KERNEL32.DLL. As for the function
LocalAlloc, I believe that the function resides at address 0x7C8099BD, and that you’ll find it in
kernel32‘s named export table in position 247.”
When the loader goes to resolve the import, it checks the timestamp of the target file on the computer with the one cached in the DLL. If they match, then it doesn’t need to do any look-ups at all; it justs uses the cached value (0x7C8099BD). If they don’t match (for example, maybe there was a
kernel32 hot-fix), it can still use the look-up hint: Before doing the binary search for
LocalAlloc, it looks directly at slot 247 to see if
LocalAlloc is there. If so, then the cost of the binary search has been avoided, and the overhead of the look-up over a pure ordinal import is just one string comparison.