2

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?

Jeya Suriya Muthumari
  • 1,947
  • 3
  • 25
  • 47
Junaid Jamil
  • 63
  • 1
  • 1
  • 14
  • 2
    "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 Jul 18 '16 at 06:02
  • 3
    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]")`](https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx). – user207421 Jul 18 '16 at 06:07
  • 2
    What do you have against def files? – David Heffernan Jul 18 '16 at 06:08
  • @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 Jul 18 '16 at 06:14
  • 1
    VB6 did not need to import by ordinal – David Heffernan Jul 18 '16 at 06:21
  • @DavidHeffernan it's an unrelated issue so I wont say much more on it, but IIRC VB6 needed the ordinals for the _names_ of the functions, without the def file (and it could have been my C++ link / export settings too, too late to check now) it couldn't locate them. – Xeren Narcy Jul 18 '16 at 06:45
  • I have copy shell32.dll to desktop and then rename to "myshell.dll" and then change the "Original file name" with a software. ordinal functions are still working. – Junaid Jamil Jul 18 '16 at 07:31
  • By using "LoadLibrary",dll become buffered to the Physical Memory (hModule is its base address). After calling "GetProcAddress",it returns the base address (FarProc) of the procedure,which is located in the ".text" section of the dll image. Even when we run any application,the app image and statically linked dlls become buffered.The functions we are using is just the base addresses of static and dynamic libraries.We can retrieve this address by assigning these to a long var. – Junaid Jamil Jul 18 '16 at 08:02

1 Answers1

5

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.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536