You can statically link functions with import librarys. You can handle the dynamic linking at load time. In this case windows handles everything for you. Or you can obtain function pointers at run time. I honestly can''t imagine that anyone can tell you more about this topic than MSDN can. You probably just searched in the wrong place

Tim

--------------------------
glvelocity.gamedev.net
www.gamedev.net/hosted/glvelocity

yeah, probably the best idea for a dll (imho) is to store loads of resources in it and use them when required... This means you can change parts of your app/game design by distributing just the new, rather than a whole new program... Also, because there is no dependancy between the dll and your app, you don''t need to link it with a lib, just load the bmps or other resources as you need them

KlDzny

normally you include your dll while you are including a .lib in the settings, but you can load a dll at runtime, something like LoadLybrary(char* name);
then its a load-time-library, else a run-time, because its loaded then at runtime.. so easy


ok, working with load-time is not so easy, but I dont want to explain for now, I wanna sleep

we wanna play, not watch the pictures

I know you prolly won''t want to hear this but I reckon you should buy Charles Petzold''s "Programming Windows - 5th Edition"... I know some people will think I am sponsored by this guy and LaMothe but the thing is, if you don''t take heed of advice from those people who are qualified to give it (cause they have experience) you won''t get far. Anyway, he has a very informative chapter on dlls and how to implement them, it takes a lot more work than throwing a lib in here and an h in there, you have to set up dependencies (in vc++ anyhoo) and then you have to set your functions to EXPORT etc... It''s complex and I only half understand it...

KlDzny

This probably summarizes something metioned above, but also gives more info.

You can load a DLL at runtime in Windows using the function LoadLibary(char *). It returns an instance handle. For example,

HINSTANCE hDLL = LoadLibrary("mylibrary.dll");

One issue. The DLL has to be labeled internally with the same DLL name, via the NAME parameter in the DEF file.

To unload the library, you use FreeLibrary(hDLL);

Now, to call a function, you have to use the function GetProcAddress, which takes parameters hDLL and a char * of the name of the method. It returns a function pointer. For example,

// declare a typedef that has the prototype signature of the
// function in the DLL we want to call.
typedef int (*FPGETNUMTRIANGLES)(Model &model);

// declare the function pointer
FPGETNUMTRIANGLES FPFunctionPointer;

// get the function pointer. may need to cast to the correct
// type.
FPFunctionPointer = (FPGETNUMTRIANGLES)GetProcAddress(hDLL, "exported_func_name");

// call the function. assume we have an object of type
// Model called model.
int numtriangles = FPFunctionPointer(model);

Inside my DLL, I must have the function "exported_func_name" defined and exported. AND, so the name isn't mangled, I have to have extern "C" around it. For example, in the DLL header file, I might have:

extern "C"
{
__declspec(dllexport) int exported_func_name(Model &model);
}

Then, to implement the function:

int exported_func_name(Model &model)
{
return(model.CountTriangles());
}

or something like that.

You *must* have the DLL from which the function pointer was called loaded into memory when you call the function. That is, don't do FreeLibrary() before you call the function. There are other issues as well, as you can imagine.

Hope this helps!

Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

Edited by - grhodes_at_work on October 9, 2000 2:34:03 PM