Dynamic Link Libraries

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

Where as a statically linked library (*.lib) is actually compiled into your program, a dynamically linked library (*.dll) is loaded at run time. The routines (functions) are loaded as needed an ran by using a pointer to a function. The plus side of a dll is that you can share functions between programs, then only update the dll as needed, rather than having to recompile both programs. Also, if there is a choice between say graphics engines, the use could select which and the dll for the proper engine can be loaded.

Hope that was clear enough
-Omalacon

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 asked about this on Saturday and I only got 2 replies . Neither of them helped me because I didn''t get an example.

All I wanted to do was make an SDK like OpenGLs SDK. You add the (*.lib) and (*.h) to your project, then compile, but I keep getting errors when it tries to link. It says there are a bunch of "unresolved external symbol" errors. When I create the dll, it doesn''t create a lib like MSDN says it will. Well I looked at the Q3A source code for 1.17, and it uses a (*.def) file that says "EXPORT" and a couple of other things in it, so I mimiked it and I had to remove all but the EXPORT word and it finaly exported a lib file, but I get the "unresolved external symbol" error still .

Can someone help me?

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

I have that book . I did what it said, but it still doesn''t function like how the OpenGL SDK setup works.

Oh, why does it have to be so hard...the pros make it look so easy.

There''s an article that was submitted to GameDev that did a good job of explaining ''Using Interface classes in DLLs''

I think that is pretty much the title. It would be a good place to start.

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