I just wanted some info on creating a DLL in Dev-C++, and using it during run-time. Sample code, or links to good tutorials would be nice also. Thanks for any help.

Take a look here:

http://www.xraylith.wisc.edu/~khan/software/gnu-win32/

ok thanx for the link, but I figured out how to get it working next to one thing. In Dev-C++, how can I specify my exports (ex: use a DEF file) so that I can specify what the name of the export should be (because when I compile the DLL now, Dev-C++ makes one for me, and the name is like msg__dVc, or something of the like)

I can't say as I've never used dev-c++ to build a dll. But looking throught the dllhelper zip file from the above link I came across this preprocessor conditional.




Um... never mind, I think you know that.

Ok. So it looks like your real question is "how can I provide unmangled names to my exported functions?"

I have the impression that with C++ some exports are supposed to have mangled names. At any rate, looking over the make file in the above zip, I noticed the line: DLL_EXP_DEF = cxxdll.def - and further down in the file it says:




I hope that helps point you in the right direction.

[edited by - lessbread on April 15, 2002 11:09:31 AM]

Ok, ill give that a try, another few things:

1: When does DLL_PROCESS_DETACH occur? Is it when the library is freed? (ie: FreeLibrary(***))

2: Is it possible to load a DLL from another DLL?

3: Whats the best way to create and access classes in DLLs? Would COM be the better way to go?

1) Microsoft can explain DLL_PROCESS_DETACH
better than i can....

2) yes.

3) __declspec(dllexport). but again, Microsoft, is better than i exporting classes from a DLL


i dunno, i don't use COM. you might want to read up on COM and see if the advantages/disadvantages apply to what your working on.

To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.

[edited by - jenova on April 15, 2002 4:27:27 PM]

Here''s another reference to exporting classes from a dll dynamically bind an abstract base class.

Hmm, the tutorials seem to help with some things, but they''re not really helping with the naming part. See what im trying to do is allow an SDK to go along with my program. People will recreate all the functions that would be in the default DLLs, but they canl change the code within the functions, allowing different modes (IE 16 bit graphics = default, 32 bit graphics in an SDK created DLL). I hope you get what I mean by that. This is why I want a specific naming convention, so the program will call the same function everytime it uses different DLLs.

Did you try tweeking the make file? If that didn''t work, you might have to ask the question in a mingw specific newsgroup. Or perhaps rewrite the dll in C taking care to use the "extern C" wrapper.

why not look at other plugin sdks to get an idea of what heppens (ie sonique, winammp, etc). basically you have two options:

1. use a completly C format. basically you have a single fucntion that is exported that returns a struct containing fucntion pointers to all the user changable fucntions. these fcuntions will be created by the user to change behavior, BUT they will use the same fucntion declaration, expect the same inputs, and return the same outputs, as the fucnctions you create in the original dll for the app. the user cannot add special functions since the app will not know about them. with a c++ compiler you wil have to use "extern c" to prevent name mangaling.

2. use a C++ approach. even in this method you use a few standard C functions (with the "extern c"). instead of return a struct with function pointers you create an empty base class (see the winamp avs sdk for a good example). it has all the virtual methods required by your app defined. users can opt to modify the method or leave it alone so they need to change only what is required. the Init() function would look like this:


you use the class as if it were the baseclass, and ONLY as the baseclass. this is what makes polymorphism so nice.

remeber you are EXPORTING functions and not create a library with which you must recompile with. you should be comfrtable with LoadLibrary(), GetProcAdress(), and FreeLibrary() otherwise you will have a tough time loading your dll and getting the fucntions from it.

i ahve done this many times use vc++ as the compiler. it works very well, and should work on all c/c++ compilers provided you can get the dll compiler. (as the info i gave is more theory rather then compiler specific).