Getting a pointer to a buffer in LabVIEW 8.5

[Tomi Maila]

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.

[Tomi Maila]

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.

[hviewlabs]

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?

[Tomi Maila]

QUOTE(hviewlabs @ Nov 28 2007, 10:27 PM)

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.

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

[Rolf Kalbermatter]

QUOTE(hviewlabs @ Nov 28 2007, 03:27 PM)

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?

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.

QUOTE(Tomi Maila @ Nov 28 2007, 04:26 PM)

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

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)

QUOTE(Tomi Maila @ Nov 23 2007, 12:08 PM)

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.

http://lavag.org/old_files/monthly_11_2007/post-4014-1195837700.png'

target="_blank">

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

Rolf Kalbermatter