DLL call, once more: help wanted

[rolfk]

Of course does it crash! MoveBlock does not allocate memory itself. So you try to copy Datalen bytes from the Data pointer into a LabVIEW string of length 0! BOOOEMMM!

[MaSta]

I hear you, but even if I do allocate memory, it crashes. See the attached VI. MoveBlock runs well with the destination being an I32 and size 4.

The 255 byte array doesn't work. I cannot get this in my head what makes LabVIEW crash here.

I get pointer to a 255 byte array, that's what DSNewPtr is described to do. I pass this pointer and the size to MoveBlock, along with an initialized byte array.

Addition: the memory is allocated by DSNewPtr.vi, but there also is DSNewPClr.vi. I'll try that one.

[Andrey_Dmitriev]

Its crashed, because you selected Data Format -> "Handles by Value" instead of "Array Data Pointer" (sorry, I don't know how these option named in German version):

In additional, you have race condition between MoveBlock and DSDisposePtr. Technically you should dispose Memory after MoveBlock done, but not parallel.

Modified VI, which should not crash in the attachment.

[MaSta]

See, that's what confuses me about LabVIEW. The option "Adapt to type" - why wouldn't it work with a U8 array? 

"Adapt to type" was set from another use place of the MoveBlock call and I didn't adapt, because I expected to work anyway. 

[rolfk]

Adapt to Type means: Use whatever memory layout is used by LabVIEW itself. For Arrays and Handles that is ALWAYS a handle. C libraries expect usually pointers unless they were specifically written to be used with LabVIEW by someone who knows what (s)he was doing!

For clusters it means to pass the cluster as a pointer to a struct with the memory alignment as used by LabVIEW: byte packing for Windows 32-bit, default alignment for everything else.

Why that byte packing? Because the LabVIEW for Windows memory model was first introduced with the LabVIEW for Windows 3.1 version of LabVIEW in 1992. At that time computers were still often sold with 4MB (yes MB not GB) of RAM and every byte saved could be the difference between an application running or producing an out of memory error. While Windows 3.1 was really a 16 bit environment, LabVIEW used a so called DOS extender to run as native 32-bit application with a linear memory model. When LabVIEW for Windows NT/95 was introduced in 1994, the LabVIEW developers decided to keep the same packed alignment rules, since this was also using the same linear 32-bit memory model and that allowed to actually reuse the 32-bit compiled CINs (which was the original form of external code support in LabVIEW before it also learned to interface to DLLs) even under Windows NT.

[MaSta]

I solved the PN Read () problem. Sometimes you don't see the obvious. The not initialized memory block for the dereferencing...