Export ordinal without def file

2
votes

We can export ordinal using def file.But the system dlls doesn't use def files.Still shell32.dll have 569 ordinal exports and user32.dll have 181 ordinal exports.

Is there any way to export ordinal without def file?

1
c++cwinapishell32
"But the system dlls doesn't use def files" - are you sure? (I'm not) It's been some time since i've had to use ordinals (VS6 anyone?) so i've been wondering as well if there's a way to avoid it. But again i'm not sure you could tell how the ordinals were created / defined for some dll. - Xeren Narcy
I agree with @XerenNarcy: I don't know what evidence you can possibly have that system DLLs weren't build with .DEF files. But you can accomplish this in the source code with a #pragma comment(linker,"/EXPORT:entryname[,@ordinal[,NONAME]][,DATA]"). - user207421
What do you have against def files? - David Heffernan
@DavidHeffernan maintainability, in a word. I add a new export function, that's enough for mangled names (or c names) if the client using the DLL can make sense of it, but say (because i used it) VB6 couldn't use MSVC6 (C++) dlls without ordinals, so every time a new function was to be exported it would need to be added to this file. otherwise agree, no beef to be had. - Xeren Narcy
VB6 did not need to import by ordinal - David Heffernan

1 Answers

5
votes

Every exported function has an ordinal. The linker automatically numbers them, it starts at 1. But if you want to control the exact value (like Microsoft has to do with these DLLs) then you must use a .def file.

It is only required if client code used ordinals before, and you require binary compatibility with old code that doesn't get rebuilt, and you added or removed exported functions. To within 99.99% accuracy, client code never uses ordinals to link an exported function. They always use the name instead. You'd only have a dependency on the ordinal value if you exported the function with the NONAME attribute in the .def file, forcing the client code to use the ordinal instead. In practice, this is only ever done when you want to hide exports.

Microsoft can never make any assumptions about this and was forced to keep these DLLs binary compatible for the past 23 years. A burden that's not ours.