LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

labview.lib or labviewv.lib?

Solved!
Go to solution

Hello,

 

I'm trying to write a C++ DLL that interfaces with LabVIEW code, that uses LabVIEW Manager functions. The linked article says I should link against labviewc.lib, but there's another similar library called labview.lib

 

What's the difference between them? Which one should I use?

Certified LabVIEW Developer
Message 1 of 4
(4,124 Views)
Solution
Accepted by topic author JKSH

@JKSH wrote:

Hello,

 

I'm trying to write a C++ DLL that interfaces with LabVIEW code, that uses LabVIEW Manager functions. The linked article says I should link against labviewc.lib, but there's another similar library called labview.lib

 

What's the difference between them? Which one should I use?


It's labviewv.lib not labviewc.lib! Generally you should use labviewv.lib for new development. It handles better about linking to the right LabVIEW kernel when you have complex situations such as a LabVIEW DLL (compiled LabVIEW VIs in a DLL) that uses your DLL and when that LabVIEW DLL is called from a LabVIEW system that is a different version than what was used to create the LabVIEW DLL. With labview.lib this scenario is very likely to create a chaos as it tries to link to the calling LabVIEW system instead of the runtime system under which the DLL is running.

Rolf Kalbermatter
My Blog
Message 2 of 4
(4,104 Views)

Thanks for your explanation, rolfk! I'll use labviewv.lib. (You're right, it's not labviewc.lib -- typo)

 

So labview.lib is deprecated in favour of labviewv.lib. Is this documented anywhere?

Certified LabVIEW Developer
0 Kudos
Message 3 of 4
(4,076 Views)

@JKSH wrote:

 

So labview.lib is deprecated in favour of labviewv.lib. Is this documented anywhere?


I wouldn't call it depreciated really. It will work in most of the cases just fine, except in the corner case where someone writes a LabVIEW VI DLL that makes use of the C DLL you link with labview.lib and someone else wants to link in this LabVIEW VI DLL into a different version of LabVIEW. 

It's not an impossible situation but rather unusual as it is quite a roundabout way of doing things. Much better would be in this case to abandon the LabVIEW VI DLL altogether and use the original LabVIEW VIs that were used to create the DLL. Much easier to maintain, debug and also gives LabVIEW the possibility to optimize various things. With a DLL interface LabVIEW has ABSOLUTELY no way of optimizing anything, and generally the datatypes passed to the DLL have to be standard C type compatible, which often requires additional overhead for converting them from LabVIEW to Standard C and back to LabVIEW. (If you use LabVIEW native datatypes for the LabVIEW VI DLL interface you limit the DLL to be only usable from within LabVIEW, which is really überstupid to do, as using the VIs directly still would give you much better debuggability and code maintenance).

 

That all said it is documented although not with as many words in the online help for LabVIEW Reference where they simply recommend to link with labviewv.lib without anymore mentioning anything about labview.lib. And here is a white paper that mentions under subheading 2. that you should use labviewv.lib if you create a shared library that is called from LabVIEW AND calls back into LabVIEW too. It mentions the situation with multiple LabVIEW runtime systems present in the same process (e.g. the runtime system under which your LabVIEW VI DLL is executed and the Runtime system under which the main VI code runs).

 

LabVIEW DLLs contain precompiled VIs that can only be loaded and executed by the same LabVIEW version that was used to create the DLL. When the LabVIEW DLL is loaded it detects if it is run from the same version of LabVIEW as it was created with and in that case links to the main LabVIEW kernel. If the versions don't match it initializes the according LabVIEW runtime version and links to that instead. labview.lib gets confused in that case as it links to the main LabVIEW kernel and memory allocations suddenly get messed up. labviewv.lib recognizes this situation and properly links with the runtime kernel that the shared library is executing in.

Rolf Kalbermatter
My Blog
Message 4 of 4
(4,057 Views)