[C++]call functions from dll

[vivendi]

If i have an executable which loads a DLL, is it then possible that the executable can call functions from the DLL eventhough it doesn't know what functions exist in that DLL ??

The executable will act like an online server which can receive commands remotely from anyone that connects to it. When the executable receives a command like "nickname" it should call the function 'nickname()' from the DLL.

But i want to do it in a way so that when i update the DLL with new functions, that i don't have to update to exe file aswell with the new function names that the DLL has.

So is there a way to make the executable look/scan for a function inside my DLL, and if it's there execute that function??

[Paul McKenzie]

But i want to do it in a way so that when i update the DLL with new functions, that i don't have to update to exe file aswell with the new function names that the DLL has.

If the DLL has 10 exported functions, how do you kinow which one to call or what each function does? You have to know the names of the function (and their purpose) before you can search for them and call them, no?

Do you have a file, database table, or something that gets updated with the names, so that you know what names to look for? Then if that's the case, all the application needs to do is read the names from this external table, file, etc. and then see if that name exists in the DLL (using LoadLibrary/GetProcAddress and checking for a non-NULL return value).

Secondly, you can get the exported function name list from any DLL. I'm not sure how you do that, programs like Dependency Walker and dumpbin can do it, so of course an application can do the same thing. But even so, the issue is that you must know what name you're looking for before you call the function, unless your DLL consists of only 1 exported function.

Regards,

Paul McKenzie

[vivendi]

I do know the functions that the DLL have and what parameters they need. I just still don't see how i can call them from my executable.

Normally i would do it like this:

typedef int (*SomeDLLFunc)(int);

//in main function
SomeDLLFunc TestFunction (0);

hinstDll = LoadLibrary ("myfile.dll");
if ( hinstDll != 0 )
    TestFunction = (SomeDLLFunc)GetProcAddress ( hinstDll, "TestFunction" );

int x = TestFunction ( 5 );

But this way i still have to compile the executable with the function names of the DLL. So if i'd added new functions to the DLL then i also have te recompile the EXE to make more typedefs for the functions that DLL has.

I want my exe to be 'standalone'. So that i can update my DLL with as much of new functions that i want without worrying about the EXE.

It's no problem to store the function names and params somewhere in a database. I can let the EXE reas that out. I just still don't see how to do it like that...

[Paul McKenzie]

It's no problem to store the function names and params somewhere in a database. I can let the EXE reas that out. I just still don't see how to do it like that...

Are you forgetting that C++ has variables and functions?

#include <string>

std::string GetNameFromDatabase()
{
    std::string nameToUse;
    //
    // read name from database.
    // do  more stuff (whatever that is)
    //...
   return NameToUse;
}
//...
TestFunction = (SomeDLLFunc)GetProcAddress ( hinstDll, GetNameFromDatabase().c_str() );

The name of the function is gotten by calling another function, and is not hard-coded. If the parameters to all of your DLL functions will be the same, then you don't need to recompile your code. The same function pointer will work for all of those functions.

If the DLL functoins have different parameters, parameter types, return values, then there may be something wrong with your design or design goals. This sounds too haphazard and not well thought out. If the functions are supposed to do some task that is related in some common way to your general application, why would the parameters, types, number of parameters, etc. be all over the place with no coherency?

Think of this like C++ classes with virtual functions. In there are n functions that are virtual in the base class, the derived class can't just make up their own function and have the base class try to call it. The derived class must properly override the base class with the exact parameter types, parameter list, and return type. Your DLL scenario should follow the same analogy.

My opinioin, It should be a certain set of functions that the creator of the DLL can write code to "override". For example, you state that the DLL can have 3 different types of functions. Function 1 must have these parameter types and number of parameters, function 2 these parameters and types, etc. Just letting the creator of the DLL do anything willy-nilly isn't going to work -- you have to lay down rules.

If you let the creator of the DLL "do their own thing", and create any function they want with whatever parameters and return values they feel like, and then have your app try to figure this out at run-time, then this is not going to work. You would have to recompile your application, the same way a base class would have to be recoded if the requirement is that the base class must know about the derived class's own functions.

Regards,

Paul McKenzie

[S_M_A]

Here's a good article as well as downloadable source code that shows you how to find the dll exports http://msdn.microsoft.com/en-us/magazine/cc301805.aspx

This will not provide the params and return types but your functions might have the same signature? If not, calling them without a prototype would be really messy even if you manage to translate the name mangled function name into param & return types.

If you want to try that, even though this is very likely to be compiler version dependent, check out for instance this link http://mearie.org/documents/mscmangle/