[RESOLVED] DLL exported functions

[Igor Vartanov]

what about the other way aorund? Can VC++ actually generate a .DEF file at build time?

It never is other way round with VC. DEF file always is an input information, and VC never generates it. It's always programmer who does. Though I can recall, Borland indeed had the tool, but not VC.

If I see this in a DEF file:-

foo1 @2

will the LIB / DLL tables contain BOTH the function name and the ordinal or just the ordinal? I'm assuming both

It will be both, yes.

The NONAME is for the paranoid, I assume that Igor did it out of habit.

Sorry, the NONAME is for those who know exactly what they do. I used it precisely for demonstrating how conflict of ordinals may occur. Other people may use it for getting rid of export names table, because they have their own reasons for that, and being paranoid might be the last one. You know, sometimes people intentionally design all the aspects of the dlls they release.

The most commonly used extension is to put PRIVATE in place of the ordinal number for predefined Windows exports like DllGetVersion().

Well, talking about PRIVATE, again it is for those who know exactly what they do. It's used strictly to prevent existing export entries from appearing in import library. And frankly, I cannot see how PRIVATE could relate to the subject we discuss here, as it affects neither export name nor ordinal.

As long as the lib and its header files match each other, the exe build will always work just fine. The linker can't know if there's a more recent DLL available.

And if the prototype stays unchanged, and .lib file contains export by name, and export really exists in the .dll, it doesn't matter how old the .lib is, as .exe is going to work just fine.