1. Dump Dev-C++, dump it now. It has been dead for over 5 years now. There is no good reason to still be using it (I have also ran into stability issues). Get a good IDE like Visual studios or Code::blocks. Code::blocks is especially a good replacement for dev-c++ if you want things to feel similar.
2. As degibson said, DLLs are just code. If you want to use it, then you need (ok, you don't NEED it, but it makes things easier to work with) header files with all the functions you want to work with. Functions to be exported have __declspec(dllexport). Functions to be imported have __declspec(dllimport) in their definitions. This is usually resolved with a macro that looks something like this
Code:
#ifdef BUILD_DLL
#define DLL_EXPORT __declspec(dllexport)
#else
#define DLL_EXPORT __declspec(dllimport)
#endif
3. Besides the export import stuff, you'll also need a DLL main function. Those are usually pretty generic. Here is an example
Code:
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
// attach to process
// return FALSE to fail DLL load
break;
case DLL_PROCESS_DETACH:
// detach from process
break;
case DLL_THREAD_ATTACH:
// attach to thread
break;
case DLL_THREAD_DETACH:
// detach from thread
break;
}
return TRUE; // successful
}
These are fairly generic as it is basically only handling how the DLL i to behave when hooking in.
4. While it is possible to do, avoid exporting classes. GCC, Microsoft, delph, et al. implement class standards differently (the C++ standard allows it). You have the distinct possibility of ending up in a world of hurt if you don't heed this warning.
5. Use stdcall when possible. Again, calling conventions can really screw you over. About the only one guaranteed to be implemented the same across the board is stdcall. In MSVC I believe it is __stdcall but in gcc it is __attribute__(stdcall) or something like that (if you googled what I type, it would come up). You loose the ability to use the ellipsis... I, however, doubt you have ever used it (and if you have, you are doing things wrong).
6. I can already see this in your future, since you are dealing with a gui. DLLs and GUIs don't generally play nicely together. That is because Win32 guis have things like message pumps in them which sort of make it difficult to put in a DLL. It is possible, but not advisable. If you MUST do it, then starting your gui in a new thread is pretty much a requirement. Unfortunately, this isn't something that is so simple where you can just send messages to the gui and have it do what you want.
I'll be frank, for this reason alone, DLLs pretty much NEVER have any graphical interface code in them (IE they don't create windows). But if you absolutely must, be prepared for a hellish experience. Windows does not allow anyone but the creating thread to call functions the modify windows resources for that thread. That means you can't intercept messages for the GUI, and you can't do things like change the position of a button. That all has to be handled by the thread that created those windows. You can call the function that gets fired on a button push, so long as it doesn't change the way the window looks (or tries to access information about the window elements) This presents a nice problem because libraries such as wxWidgets go to great lengths to hide all code specific to windows. So you really don't know when a function will touch something i shouldn't.
Whats worse, you can't change the way the message loop behaves with wxWidgets. You are stuck with their message loop. What you can do, is use the Windows PostMessage API to send messages to the thread, but you get the wonderful opportunity of finding out exactly how the messagepump works if you want to rely on that.