Hi,

Have you ever wanted to know what's the pointer to a LabVIEW buffer? Well in LabVIEW 8.5 you can actually find it out. LabVIEW 8.5 supports calling a shared library with constant arguments. As the arguments passed to the shared library are considered constant, LabVIEW reuses an existing data buffer for the shared library call. It doesn't make a copy of the data to pass the copy to the shared library instead of the original data. This allows reading and modifying wires parallel to the shared library. If these wires share buffer with a constant, then the value of the constant can be read modified as well.

So what's the trick? Well, to understand the trick we first need to understand how LabVIEW data is stored into memory. LabVIEW uses two kind of memory models for data. For fixed sized data such as numeric types, booleans, clusters and references LabVIEW users pointers to the data to pass the data around. Each buffer is therefore referenced with a pointer to the data. For variable sized data such as strings and arrays and apparently also LabVIEW classes, LabVIEW uses handles (pointers to pointers) to the data.

I think this is enough of introduction. I don't want to spoil all the fun. Take a look by yourself how to find out the pointer to fixed sized buffers and the handle to variable sized buffers.

As Rolf pointed out, if you use "LabVIEW" instead of "LabVIEW.exe" as the value for the "Library Name or Path" control in the Call Library Function dialog, then the code will work in the built app as well as in the development environment.

Apparently, using "LabVIEW" there opens a way to a lot of LabVIEW functionality. However, except for the ones documented in the "Using External Code in LabVIEW" manual, where can we get the description/prototypes for those functions, I wonder?

Oh. I thought it will only work in all supported platforms but not in a build app unless you used labview runtime instead of the executable. Well I guess Rolf is right here. He's such a guru in these things

You can try to get NI to give you this for certain functionality under an NDA. Changes that you will get it are however very close to 0%.

Reasons you could get that information basically boil down to this:

1) Show NI that they can sell several hundred extra LabVIEW licenses if they give you that information or that they will get a multi million hardware sale.

Reasons why they don't want to do this:

1) Many of those APIs do nothing useful for any possible client other than LabVIEW itself.
2) Many depend on other functionality not exported directly at all.
3) Every documented API needs to remain fixed for the rest of LabVIEW's lifetime to avoid breaking existing apps outside of NI's control.
4) Some of the APIs could reveal sensitive information if fully documented.

So go and figure your chances.

There is no difference between using the runtime and a LabVIEW executable since about LabVIEW 4.0 or so. Before that a LabVIEW executable was self contained, with the entire LabVIEW runtime embedded in the executable itself. Since then every LabVIEW executable will always refer to lvrt.dll whenever wanting to do any LabVIEW specific operation.

And yes using LabVIEW (case very important) instead of LaBvIeW.exe should since about LabVIEW 6.0 also work in an excutable/runtime environment. The Call Library Node contains specific code detecting that keyword and directly rediricting to whatever kernel is doing the LabVIEW nitty gritty work at that moment. (lvrt.dll or labview.exe)

A correctly configured MoveBlock call can do the same as your GetValueByPointer since LabVIEW 5.x already.

Rolf Kalbermatter