LabVIEW
Question about the path of Call Library Function Node
Hi, LV community, this is a question not a problem I need to solve. It is just something I don't understand.
I downloaded the Bitflow framegrabber LV driver from Current Downloads (bitflow.com) and install them by copied them to the LVdir/vi.lib/addons/Bitflow folder (I installed the SDK first, then LV drivers). They are a bunch of llb files and a dll file, which is LVdir/vi.lib/addons/Bitflow/vss_bitflow.*. Obviously, many of the VIs uses the CLFN to call functions in this dll file and there is a Library Name or Path setting to point where the dll file is. What I don't understand is this path changes when the llb files are in different locations. For example, If the llb files are copied to the LVdir/vi.lib/addons/Bitflow folder, the dll path is automatically configured to LVdir/vi.lib/addons/Bitflow/vss_bitflow.*. But if the llb files are copied to Download/vi.lib/addons/Bitflow, the path is automatically configured to Download/vi.lib/addons/Bitflow/vss_bitflow.*.
This is very convenient and handy, save me from changing the path for every call in the library. But I just don't understand how it works because I thought the dll path is static. Another silly question is how could I set it to a static path? Probably nobody is going to do it but just wondering how it can be done. Thanks
LabVIEW's Call Library Node has some tricks in its sleeve to try to work around some of the Windows specific shared library search difficulties. Not all of them are very obvious and some can under certain conditions actually have undesired effects.
Basically the name you see in the Call Library Node is a combination of two things:
1) What you initially enter
2) What LabVIEW determines to be the path after the library was successfully loaded
But, it somehow remembers what you initially enter and will try to use that path anyways next time you load the VI again.
There are certain particularities to know about this:
- If you only enter the library name alone without any path, LabVIEW will request from Windows to find that library name. Normal Windows DLL search rules apply. The DLL will only be found if it is in one of the locations that Windows knows to search. In addition if you build an application executable, the application builder will assume that such a library is a standard library on the system and not attempt to copy it into the application directory as a private copy. This is very important when you interface to standard Windows DLLs. Every Windows installation comes with its own set of such DLLs. When an application tries to load its own private copy of it, things go usually totally haywire. First that private copy is almost certainly not the exact same version than what another users system may use. Second those system DLLs internally manage all kinds of handles and other variables and the handle created in the DLL in your Windows system has no relevance to a handle created in your applications own private copy of that DLL. Result, both DLLs are trying to fight each other and usually much sooner than later will cause a fatal application crash.
- When you enter the full path, LabVIEW goes through a little more trouble. First it asks Windows to load the DLL from that path. If that fails it adds the current project path (if present) to the search directories for Windows and asks Windows again to load that path. If that fails too, it strips the path to the filename only and lets Windows try to figure out where that DLL could be. And the application builder will consider such a DLL to be an application specific DLL and include it into the build by adding it to the support folder (default name "data").
In any case, after the DLL is loaded successfully, the path control in the Call Library Node is usually updated to show the full path the DLL was loaded from. And any other Call Library Node referencing that same DLL is updated accordingly too.
So for the most part (aside from the LabVIEW project specific directory), the actual searching and loading of the DLL is entirely up to Windows, and Windows standard search rules apply. But LabVIEW normally will update the Call Library Node dialog library path after the DLL is successfully loaded. And it will remember the original path you entered in the VI.
When building an executable, the application builder will adjust the path to point to the private copy in the support folder, for DLLs it copies over, and leave the library name only in the Call Library Node for DLLs it determined to be system provided libraries.
If LabVIEW appears to find the DLL from your Download folder this is because Windows somehow determines that this is a location to be searched for DLLs. And that would be a potential security hazard.
Normal Windows search rules are as follows: https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
for desktop apps, which LabVIEW is it's mostly like this:
1) if DLL name is already loaded into current process, irrespective of the requested path, use it
2) if the DLL is a "KnownDLL", it is loaded from the location specified in the registry
3) if the path is a full absolute path, Windows tries to load the DLL from there and fails if it can't load it
4) look in the current processes application directory for the DLL name
5) look in the <system> directory for the DLL name
6) look in the <windows> directory for the DLL name
7) look in the "current directory" for the DLL name
8 ) look in any directory listed in the PATH environment variable
@Louis.J wrote:This is very convenient and handy, save me from changing the path for every call in the library. But I just don't understand how it works because I thought the dll path is static. Another silly question is how could I set it to a static path? Probably nobody is going to do it but just wondering how it can be done. Thanks
To answer your second question, have you noticed the checkbox underneath the path field? Once you check it, you get a path input where you can wire any suitable static file.
And yes, I do that sometimes (example, but start reading here for context)!
