4

Is there any way to check for parameter existence in a function inside dll (using Delphi 5)? Let's say I want to call MyFunction() in MyDll.dll but I am not sure if the lately added parameter exists or not. This is needed for backward compatibility reason.

I found the useful topic here: How to check a DLL if a function exists?

I tried it and it works for me. But is it possible to extend it to get all the parameters of MyFunction()?

Thanks in advance.

Regards,

Alex

Community
  • 1
  • 1
pyfyc
  • 127
  • 2
  • 9
  • In short - it's impossible. If you need backward compatibility - rename new function to `MyFunction2`. – kami Mar 22 '16 at 05:18
  • The rules are that an interface must never be changed once it has been published. – David Heffernan Mar 22 '16 at 07:11
  • As David said, don't ever change the interface. You can add new functions that extend the functionality of the "old" ones, but these should never change. – Rudy Velthuis Mar 22 '16 at 08:18

1 Answers1

4

No - it is not possible from a standard Windows DLL to ascertain the parameters used in an exported function. The only information available to you is the name and/or the ordinal number of the function (which both points to the entry point in the .DLL of the first instruction of the exported function).

If the .DLL is made in Microsoft C++, you can use Name Mangling, but this will in essence make a new exported function each time you change the signature (parameter list and/or return value) of the function, thus will eliminate backwards compatibility (the parameters of the function is appended to the exported name in encoded form, so that - f.ex. - an exported function

void MyFunc(int p1)

will be exported as (just making it up here, to illustrate):

MyFunc@jefal8936

and if you change it to

void MyFunc(int p1, char p2)

then the exported name could suddenly become

MyFunc@kaybx42

Thus an old compiled program that linked to MyFunc@jefal8936 wouldn't be able to find its entry point any more (and would thus fail to even load if linked with static linkage).

The only way to accomplish what you are attempting to do is to make a new exported function in your .DLL (one convention is to use FuncNameEx as the "extended" version with additional parameters) and then you can call FuncNameEx from your older FuncName function (assuming that you can "translate" the parameters of the old function to the new one).

HeartWare
  • 7,464
  • 2
  • 26
  • 30
  • If the exported function is mangled at all... A good C++ programmer will get rid of name mangling when exporting from a DLL. – Rudy Velthuis Mar 22 '16 at 07:35
  • 2
    The name of the function isn't the *only* information available. There's plenty of other metadata, such as the DLL's version information, the names of other functions, and even the size of the file. They could all indicate which edition of the DLL is in use, and therefore tell which parameters this function expects. (Providing a distinct new function is obviously the superior choice, if it's available.) – Rob Kennedy Mar 22 '16 at 13:00
  • Yes I agree with your point about following programming standards. But in my case I have to cope with what I have as I am working on a project that started 15+ years ago with many programmers involved and where not everybody was following standards. So i am choosing the solution from Rob Kennedy. I will check the dll version and depending on that will call MyFunction() with or without new parameter. – pyfyc Mar 24 '16 at 01:38