views:

27

answers:

1

Beyond creating a dll with all the same functions with the same interface and calling conventions, does the replacement dll need to exactly duplicate the export map including ordinal numbers of the original as well? So that not only explicit loading via GetProcAddress works, but implicit linking as well?

(edit: this is an unmanaged, c/c++ windows dll I'm talking about, not .net)

+1  A: 

You will need to mimic every export that any other client is using, you don't need to mimic "dead" exports that no one is using. You need to keep the ordinals only if other clients are linked by using ordinal instead of export name (which is quite rare).

There a is something that you need to keep in mind: If the dll contains C++ classes and it is not using extern "C" then you need to maintain binary comparability, meaning the classes in the replacement dll needs to have the same fields in the same order as the original classes. If your using interfaces that you need to keep the vtable with the same arguments for each method.

Shay Erlichmen
Thanks! I hadn't thought about classes. I think my particular case is just "C" functions so just specifying ordinal in the .def file should do it. I noticed in "dumpbin /exports" that there is also a "hint" column, does this need to be preserved as well, or can that differ without breaking compatibility?
Bogatyr
Oh, one more thing. The "dumpbin /exports original.dll" contains multiple entries for the same entrypoint: "foo" and "foo@4", at different ordinal numbers, but identical entrypoint. How do I create these extra "@n" aliases in the export map?
Bogatyr
@Bogatyr its the size of the parameters, foo means no params foo@4 is foo(int), foo@8 means foo(int, int)
Shay Erlichmen
The library I was creating a replacement for had both "foo" and "foo@X" symbols in the export table for the same entrypoint. I had to create aliased entries in the EXPORTS section of the .def file that pointed to the single entry point
Bogatyr