LabVIEW
Latest version of the 'Using External Code in LabVIEW' Manual?
Solved!
@AdamZeroK wrote:
Hi Michael,
Thank you for your reply. I am pretty familiar with the CLN, its basic features and DLL's generally. I am not up against a specific problem right now that I can't solve. However, as an example, I am going to be using DSNewPtr to allocate some memory and pass a pointer to that block over to a DLL (for a camera) for it to fill in at a later time; I wanted to make sure LV wasn't going to mess with (move/free/edit) the memory in the interim.
Since you are here here's a few specific Q's: is the AZ zone gone? Will the memory manager/garbage collector ever move/ free memory i allocate in the DS zone? If so, can i just not worry about the use of 'locks' for this memory?
LabVIEW 2 up to about 5 or so had separate AZ and DS zones. AZ memory was Application Zone memory and could be relocated dynamically. It was only used internally in LabVIEW for various functions but nothing that was exposed to the diagram did ever use AZ memory. The internal memory manager was allowed to relocate AZ memory at any time unless it was marked as locked, to defragment the memory and make room for new memory allocation requests. The design came from the Apple Macintosh which had by modern standards a somewhat archaic memory management and was then ported by NI verbatim to the other LabVIEW platforms. For Windows 3.1, which was the first platform where LabVIEW was released after the Mac, it made actually some sense too, as its memory management was even worse than on the Mac. LabVIEW even used its own memory manager internally that they licensed from a third party to have a better performance than the Windows 3.1 memory manager, which definitely had serious trouble to handle the amount of memory LabVIEW did use at that time (4MB of RAM was the absolute minimum you had to have installed in the computer, but you really needed 8MB of RAM to have a nicely performing system, and yes that was considered a lot of memory in 1992 
).
DS memory could never get relocated unless it was explicitly resized by a call to DSSetHandleSize().
At around LabVIEW 6 or 7 the AZ memory type was completely removed from LabVIEW as the then available memory managers in the OS where starting to get pretty good in doing what they were supposed to do originally, also thanks to pretty efficient assistance of hardware memory management units fully built into the CPU at that time, and the difference between AZ and DS memory did not make much sense anymore.
So for writing external code including CINs, the AZ functions were never really useful, except for some people with NI internal knowledge, as the functions that could use AZ memory, where although partly exported, never publicly documented. After removal of the AZ memory type in LabVIEW, the existing AZ functions were for backwards compatibility not removed but simply linked to the existing DS functions of the same name. This was valid as the only restriction for an external user of these functions was that you could not use DS functions on memory allocated with an AZ function and vise-versa.
And yes, once you allocate memory with an explicit call to DSNewPtr() or friends, you absolutely have to call DSDisposePtr() yourself to dispose that memory. LabVIEW follows the standard principle, that whoever allocated a memory block is responsible for de-allocating it too.
For handles this can be a bit different though. If you use DSNewHandle() or another function to create a handle and pass the resulting handle back to the diagram as a properly formatted array or string handle, then you do not own that handle anymore after your function returned from the Call Library Node. Handle ownership is passed along to whatever function receives it, unless you configure the corresponding parameter in the Call Library Node configuration to be of type constant. In that case LabVIEW assumes that the function will NOT modify the handle nor its contents and may schedule other parallel diagram nodes that receive the same handle to be executed after your CLN returns from the function, in order to avoid having to create a temporary copy of the handle for both functions.
I would just add this excerpt from Using External Code in LabVIEW to Rolf's excellent answer:
LabVIEW uses the data space (DS) zone only to hold VI execution data. LabVIEW uses the application zone (AZ) to hold all other data. Most memory manager functions have two corresponding routines, one for each of the two zones. Routines that operate on the data space zone begin with DS. Routines for the application zone begin with AZ.
Currently, the two zones are actually one zone, but this might change in future releases of LabVIEW. Therefore, you should write applications as if the two zones actually exist.
External code modules work almost exclusively with data created in the DS zone, although exceptions exist. In most cases, use the DS routines when you need to work with dynamically allocated memory.
All data passed to or from a CIN is allocated in the DS zone, except for Path, which uses AZ handles. You should only use file manager functions, not the AZ memory manager routines, to manipulate Path. Thus, your CINs should use the DS memory routines when working with parameters passed from the block diagram. The only exceptions to this rule are handles created using the SizeHandle function, which allocates handles in the application zone. If you pass a handle created using the SizeHandle function to a CIN, your CIN should use AZ routines to work with the handle.
I was always wondering, why they write that AZ and DS will become one zone in 2003 (time when LV 6.1 and 7.0 Express were already released) and according to Rolf AZ and DS were already united. And when exactly this change will happen... As for now it seems to never happen, because the work on Memory Manager functions is almost zero priority and even meaningless on the background of NXG and its completely different manager (which currently seems not to be exposed to the users yet).
Also I would note that forementioned SizeHandle function is absolutely of no use on 32- and 64-bit platforms. Size Handle, Handle Peek and Handle Poke VIs existed on LV palettes of LV 2.5 and maybe earlier versions and corresponded (more or less) to AZNewHandle / AZSetHandleSize and MoveBlock for reading from and writing to the handle. Those VIs work only on 16-bit and 16/32-bit OS'es such as Windows 3.1, 95 or 98. For anyone's interest there's a little more about this piece of history:
http://info-labview.org/ILVMessages/1993/10/06/Info-LabVIEW_Digest_1993-10-06_002.html
http://info-labview.org/ILVMessages/1994/04/22/Info-LabVIEW_Digest_1994-04-22_004.html
@dadreamer wrote:
I was always wondering, why they write that AZ and DS will become one zone in 2003 (time when LV 6.1 and 7.0 Express were already released) and according to Rolf AZ and DS were already united. And when exactly this change will happen... As for now it seems to never happen, because the work on Memory Manager functions is almost zero priority and even meaningless on the background of NXG and its completely different manager (which currently seems not to be exposed to the users yet).
It has happened. AZ does not exist anymore although the LabVIEW runtime still exports the functions for backwards compatibility. However those exported AZ functions simply are redirected to the according DS functions and for those that do not have a matching DS function (eg. Lock functionality) they simply call an empty dummy function that does nothing. As to when that exactly was I beg you to give me a bit of leeway. It was somewhwere around LabVIEW 6 or 7, but that is about 20 years ago so a few years really don't make that much of a difference nowadays.
Also I would note that forementioned SizeHandle function is absolutely of no use on 32- and 64-bit platforms. Size Handle, Handle Peek and Handle Poke VIs existed on LV palettes of LV 2.5 and maybe earlier versions and corresponded (more or less) to
Those SizeHandle functions only were useful on the original LabVIEW for Macintosh version. They were ported over to the multiplatform version of LabVIEW for backwards compatibility, but were not available in the palettes on non Macintosh versions of LabVIEW as they made absolutely no sense there, since Handles as LabVIEW was using them, was not an OS datatype like on the Macintosh.
The presence of those nodes in the 2.5 palettes is most likely an oversight rather than intended. They make very little sense and for DLLs even less, since on Windows nothing outside of LabVIEW will make use of such handles. LabVIEW handles are a LabVIEW speciality, except on MacOS Classic where they were simply OS handles.
As to being useful to interface to DLLs, there is another reasons that they weren't useful at all. LabVIEW only got a Call Library Node in LabVIEW 4 with very limited datatype support, due to complications on especially Windows 3.1 with the entirely different memory model of 16-bit DLLs and the flat 32-bit model LabVIEW was internally using. Everything even remotely resembling a pointer had to be marshalled with special routines that Watcom C provided and that involved very involved assembly code. So allowing to pass native LabVIEW datatypes to a DLL was not only almost impossible to do but also highly useless as the 16-bit DLL would never have been able to do anything with that data.
The Call Library Node only got additional support for more involved datatypes after the Windows 3.1 version of LabVIEW was completely axed, so that the memory model of LabVIEW and the DLL/shared library it called were both the same on all platforms. See here for an overview of the development to interface to external code in LabVIEW.
The only fully supported way to implement such code was by implementing CINs. They were operating in the same native 32-bit memory model as LabVIEW itself and could do all kinds of things but there was still no useful purpose to deal with LabVIEW handles on the diagram level as if you had an array or string (which was internally a handle) you much better were using the array or string nodes to work on them.
These functions only made sense on the Macintosh where you could interface to system APIs through the use of CINs that might expose OS handles, in order to access the contents of those handles without having to copy them into a LabVIEW array first. But it was very error prone as the handle was a generic datatype that did not say anything about how the data was effectively arranged inside the handle.
