Making DLLs.

[Baker]

I had lost procrastinated in messing around making a DLL (I favor the .lib-less method, but I get the advantages of the other way).

Really setting up a project file is the only barrier, after that it is smooth sailing and rather easy:

The short version --- glossing over platform differences and using Windows as an example:

DLL source:

Code: Select all

#include <stdio.h>
#include <stdarg.h>


#define DLLEXPORT __declspec(dllexport) // This is a Windows define, btw ...

DLLEXPORT int Number_Get (void)
{
   static int counter = 0;
   return ++counter;
}

Project that uses DLL:

Code: Select all

#define APIENTRY WINAPI  // On a non-Windows platform, this APIENTRY would likely be defined as "nothing" to smooth over platform differences.

int (APIENTRY *Number_Get) (void); // Function prototype

int dllhookup (void)
{
   int         loaded_ok = 0;
   HINSTANCE   hDLL = LoadLibrary(TEXT("mydll_debug.dll"));  // Load the DLL

   if (hDLL)
   {
      if ( (Number_Get = GetProcAddress(hDLL, "Number_Get") )   ) // Wire up the function but looking up the procedure name
         loaded_ok = 1;
      else
         loaded_ok = -1;
   }

   return loaded_ok;
}

This glosses over macros commonly used to "automate" the above, the calling convention stuff, platform slight differences and such. And memory ownership.

[Spike]

that code will crash due to mismatched calling conventions.
additionally, stdcall functions must generally be exported using .def files, to avoid additional name mangling (and cannot support variable arguments).
Its generally easier to just stick with the default cdecl calling convention, if its an api defined by yourself and limited to just C/C++ code.
Also, you can use LoadLibraryA and get rid of the pointless 'TEXT' macro.

memory malloced within one module must be freed within that module. each module has its own set of runtimes, which may be incompatible or use globals. If you have a Create function, you must also have a Destroy function within the same module (windows' COM stuff gets around this by the refcounted Release function being within the module that allocated the object, thus avoiding the use of free on random objects).

[Baker]

that code will crash due to mismatched calling conventions.

I think that actually worked for the wrong reasons (i.e. no arguments so calling convention didn't matter). I was trying to keep one eye at looking at, say, the Linux way of doing stuff and try to plan ahead, but yeah I found that wasn't right (I received the mixed calling conventions error).

you can use LoadLibraryA and get rid of the pointless 'TEXT' macro.

The TEXT thing is ugly, but was in the MSDN docs but yeah I'd prefer not have that (using the A functions).

memory malloced within one module must be freed within that module. each module has its own set of runtimes, which may be incompatible or use globals.

Found out about that one too (i.e. wrong heap error). I didn't actually expect that to work, I more wanted to see what would happen.

If you have a Create function, you must also have a Destroy function within the same module (windows' COM stuff gets around this by the refcounted Release function being within the module that allocated the object, thus avoiding the use of free on random objects).

Is this referring to running FreeLibrary to shut down the DLL?

Misc note: The MSDN docs which are rather C++ oriented, finding C oriented info for Visual Studio seems to be a bit tough.

[Spike]

that last part was just general good programming practise. creator destroys. avoids all sorts of issues like wrong heaps.