I noticed the current tux_driver.h file contains some code to initialise the dll, load the functions etc.
Generally having code in .h files is something I am not too keen on (as if you have multiple files in your project that want to include this .h file for whatever reason you end up with the same function being compiled in multiple times (and eventually giving linker errors.

For linux this is not really needed. In order to use a shared library you just include the .h file (without any load functions) and make sure the libray is linked with your program. In that case you are making a shared library.

However it is also possible to invoke the shared library in a dynamic way.
This is useful if you don't know if the lib exists or if you have multiple libs that export the same symbols (and want  create some form of plugin system). in that case no inclusion of the .h file is needed and the lib does not need to be linked with your app. This is what the test program does.

Question is: what is the preferred way to interface with tux_driver.
I'm inclined to go to the shared library model (and not the dynamic one), but before making the change I'd like to know what others think about this (and what the impact is for the Windows version)

Your opinion is appreciated!

FM

BTW: forgot to include this, but here is a nice page on shared libraries:

http://www.faqs.org/docs/Linux-HOWTO/Program-Library-HOWTO.html#AEN304

For me I see the dynamic loaded libraries as a convenient way to extend an existing program, for example plugins.

Linked libraries are made to simply reuse existing code.

So, for me you should stick to simple shared libraries (and even static libraries why not) with some clean header files (with a clear separation between the headers needed for using the library and headers defining some libraries internals.)

The last week, I included the static linking of libtuxdriver in the project. The 2 solutions are now available

And it's compatible with Windows too.