"LabVIEW" CLN calls: are we supposed to know?

[ensegre]

Off the head, I think that it may be common knowledge on this site that some functions are realized via CLNs which call certain procedures, with "LabVIEW" as library. I don't have a particular link to prove this, but somehow it is my off-the-head, long lurker impression. Certainly "LabVIEW" is not a smart search term here. The intriguing fact about the "LabVIEW" dynamical library is that the application resolves it opaquely, perhaps (from minimal explorations I did on Linux and windows versions) even pointing at differently located dynamic libraries on different platforms.

Now, is there some semiofficial resource about this? The reason I'm asking is actually the following: I think I could offer a nice addition to a nice project here on the site, using native LV calls, by providing a couple of VIs which implement such calls. The concern is: would I be breaching the LV licence if I did? [apart of "it's private stuff, don't cry if"]. The alternative would be to locate a really suitable external library, interface it, maintain it; a much larger hassle.

[Rolf Kalbermatter]

Well, this may be not an official NI document but it is an example being published over 12 years ago.

It sort of documents the use of the LabVIEW keyword in the Call Library Node as library name, to refer to the internal LabVIEW kernel functions. It is also used in various places in VIs inside vi.lib, so not very likely to change over night either. The fact that you could refer to the LabVIEW kernel functions through use of this keyword is more or less present since the Call Library Node was introduced in LabVIEW around 5.0. Changing this now would break lots of code out there, which either inherited some of those password protected VIs from vi.lib or custom made libraries that were created by various people. I'm personally not really to much concerned that this would suddenly go away. How and if it is supported in LabVIEW NXG I haven't looked at yet, but unless you want to be NXG compatible too with your library, which I suppose will impose quite a few other more important challenges than this, I would not bother.

[smithd]

Many of the calls are documented in the help, so yes I'd say we are supposed to know.

Some of the pointer calls are wrapped here

Chapter 6 of this also describes the functions all in one place, although its quite old: http://www.ni.com/pdf/manuals/370109a.pdf

Edited June 22, 2018 by smithd

[Rolf Kalbermatter]

Well the function documentation has been there since LabVIEW 2.5. There was even a separate printed manual just for them (and a chapter or two about writing CINs). The documented use of these functions is to call them from external code, originally from CINs and later from DLLs. Officially there is no documentation that I can remember that states that the Call Library Node can be used to call these functions by using LabVIEW as library name.

As ensegre writes, he is aware that especially here on Lava it is sort of common knowledge among people who care, that this possibility exists, but it would seem to me that he looks for a more official source for this that comes in some way from NI.

As mentioned I'm not aware of such an official statement in any documentation that could be attributed to NI or an employee that speaks for NI. So he will probably have to live with the supporting facts that make this a long standing, stable and unlikely to disappear feature that is known in the developer community outside of NI. As long as you call the documented LabVIEW manager functions, knowing what you are doing (calling MoveBlock() with bad parameters is for instance a serious hazard and the nature of the Call Library Node has no way to protect you from shooting in your foot with a machine gun!) there is nothing that could prompt NI to remove this feature from LabVIEW classic. It may be present or not in NXG for various involved reasons.

Edited June 22, 2018 by rolfk

[ensegre]

I see, thanks Rolf and smithd for the pointers. Setting aside the stability and future support of private stuff, about which I agree with Rolf's first comment. Let's suppose that I "guessed" the calling sequence of one core function, one which is for example (linux) inside /usr/local/natinst/LabVIEW-2017/cintools/liblv.so along with those of the old list, but not one of them. If I release code based upon this guess, would I place myself on the bad side?

[Rolf Kalbermatter]

Sorry I"m not sure what you try to say.

But generally unless the function is documented in the External Code Reference Manual, calling it is certainly playing with fire Those documented functions are fairly guaranteed to not go away, and 100% sure to not suddenly change the signature (parameters and their types). The documentation also states what you have to watch out when calling this function and which parameters for instance could accept a NULL pointer if not needed. Nothing of this can be "guessed" from just the function name in the shared library export list. And even if you guess everything right, there is no guarantee at all that this function will stay in future versions, or won't change the parameters somehow, as the developer just has to make sure to update any internal code that calls this function and can rightly assume that nobody else was making use of that function as it is not documented.