DLL/shared library

The first question would be if you really need to do this. While it is a powerful tool it is also tedious work to have to interface to external code through DLLs/shared libraries.

For the rest of this text I will refer to shared libraries but this should be always read to mean DLLs too, which is the term Windows uses for shared libraries.

With the Import Library Wizard in LabVIEW 8.2 a lot of the actual work of interfacing has been automated but this is just an automatic tool and it can not do everything for you. Especially for more complex shared library interfaces it simply has to fail for particular functions and those are also the ones that are likely to take up hours and hours of fiddling, testing and learning about how a C compiler actually puts variables into memory.

The shared library interface in all OSes so far was designed for and around what C needs and can provide. Therefore one needs to know some basic principles about C and for more complex interfaces also relatively intimate knowledge about how a C compiler actually puts up things in memory and such. This is a very steep learning curve for someone not already familiar with C.

An extra difficulty is that the shared interface has none of the more modern features like automatic type checking and parameter validation like what ActiveX and .Net provide for instance. This means that one single error in the configuration of the Call Library Node or a bug in the shared library itself can and usually will have fatal consequences sooner or later. This can in the best case show as a Protection fault error dialog at runtime of that function, but can also cause so subtle damage that LabVIEW will only crash at some later point when trying to access information that was destroyed earlier on. One possibility is for instance that it will often crash when you try to close LabVIEW since it tries to deallocate resources that have been destroyed by a misbehaving shared library or configuration thereof earlier on.