My choice would be the PATH environment variable for your development system and to make sure all the DLLs are installed in the same directory as the exe file for your built application. You do not want potential users of your app have to fiddle with the PATH variable! We don’t live in the 80ies of last century anymore!
Copying all needed DLLs to an exe’s own directory, when they are not installed by a manufacturer provided installer to a system wide location, is a fully valid solution. Except you do not want to clutter the LabVIEW directory itself with such DLs as it is not your application and you can’t be sure that a DLL you put in there could badly affect LabVIEW as it might conflict with a privately called DLL in LabVIEW itself.
If Kinova wants to be s real product provider and not just another hobby shop putting out some hardware to be forgotten in two years, they should think about how to provide a real installer for their driver DLLs that takes care about putting everything in the right place to be found by applications. Bonus points for a well tested LabVIEW driver besides C code examples and the nowadays unavoidable Python library.😀
As to creating your wrapper DLL: Some flat struct array like for your GetDevices function is slightly cumbersome but doesn’t require a wrapper. Only when you start to have pointers inside structs or so called callback function pointers does a wrapper get fairly unavoidable. Fairly, because even that could be done but the resulting solution suffers from a requirement for different code for 32-bit to 64-bit, a lot of difficult address calculations that a C compiler.normally simply does for you and for callback functions an extra LabVIEW generated DLL that is also bitness specific. All in all a maintenance nightmare.
For fairly simple DLL interfaces as this seemed to be, a wrapper DLL adds not really much convenience to the table. You can always start to create such a DLL when you encounter APIs that have more complicated interfaces..
What if there is no built application? I'm looking at making a VI library that is an interface between LabVIEW and the arm.
And to be fair to Kinova, this is a old model, the newer model API's are much better. This is also not really a robot arm designed for research use, its primary market is a human assistance device for people with disabilities and the SDK works well with compiled applications. Plus they do have a well developed ROS interface that most people would use, just didn't fancy running that on top of LabVIEW when I can call the DLL's directly.
In that case it gets a bit more complicated but can be done. Before you execute the Init() function which tries to load the secondary function DLLs do a LoadLibrary() call for every secondary DLL you need. Store the according handles somewhere and then call the other functions. When uninitializing your driver, free those handles.
Several caveats: if there are multiple secondary DLLs you may have to load them in a specific order from bottom up, if they depend on each other.
Most likely you can free the handles right after calling the Init() function since that function loads the DLLs itself and keeps them in memory for as long as it needs them. Since you loaded them first from the path you know you put them relative to your VI, Windows will simple see that they are already loaded when the DLL asks to load them, increment an internal usage counter and give the DLL the same handle back. When you now free your handles, Windows decrements the usage count and since it hasn’t reached 0 yet, leaves it at that.
You may want to prepare your loading code to actually check that the DLLs are where you expect them and if not try to find them in the data folder relative to your program directory. Then document in your library document that one has to add those DLLs in the build specification to the Support directory when building an application.
This all can be still fully done in LabVIEW without the.need for a wrapper DLL.
Of course you could also simply detect that you run in a built application and skip the whole preloading altogether and tell your users in your documentation to add those libraries to the root folder of any built application they create with your library.