How's THIS for a programming question...

BGNG said:

While I am well familiar with the operations of C++, the extent of my work done with it is nothing more than linear procedural stuff made exclusively into DLLs for me to use in Visual Basic.

But in the light of my current project, there is a DLL I wish to make and document it for anyone to use. But there's a problem: I don't know how to incorporate DLLs into C++ programs, nor can I find any straight-forward documentation on how to do so. Any experiments with the LoadLibrary() function have failed, and I'm not sure how to go about doing it.

What I want to do is have a declaration module that references a DLL file only. No .LIB or .OBJ files involved. I would LIKE to have it all wrapped up in one tidy .H file, but I'm uncertain if that is possible or not.

How would I make such a header file to access, say, TheFunction() from a DLL, and only a DLL in C++?

Click to expand...

All right first of all do not pass objects from or too a DLL unless both programs are compiled with the same compilor. As for the definitions of the header file for the functions etc. Well just do it for making the DLL only. I do not recomend to use the same header file in the program that uses the DLL. I've made DLL's in Borland C++ Builder and in VC++5.0 (because it's all that works on win98 still maybe? ). For importing your DLL interface I suggest creating function pointers in the object that are called by your program. This is how I handled importing and exporting data with PSXmemtool. Basically PSXmemtool was written by someone else using data base software. The DLL's however used BCB. We couldn't find a way to non statically link access for the DLL's (IE add a new module say for Chrono cross game editing). I made a DLL for managing the DLL's I was making that PSXmemtool statically loaded. This allowed one to use FF7's DLL FF8's DLL FF9's DLL or chrono crosses DLL pretty much by droping the DLL in the folder for the DLL's. No changes were needed for the main program (if the interface changed it was fixed with the DLL manager DLL ).

Anyhow Accessing the DLL's was done via C type functions only. OOP DOES NOT WORK WELL WITH DLL's because of differences in compilors and how they create objects. That's a hard lesson learned too You also have problems with C++ objects and name mangling with DLL's. Just don't try it, because you'll NEVER find things quite right.

As for loading the DLL you need to use certain windows functions to do so.
Use LoadLibrary to load the DLL it returns a type of HINSTANCE you need to check if HINSTANCE is null to see if there was an error.

Use FreeLibrary(HINSTANCE) to remove the library you loaded (HINSTANCE is the one returned by LoadLibrary).
To get the functions you need to use
GetProcAddress(HINSTANCE, "<name>");
You need to know how your compilor names the functions also. Don't assume they will be what your function names are when you passed them. I suggest using a little util to list all the exported functions in the DLL. to be sure what the naming convention is.

Cyb