Is LabVIEW a Functional or Object-Oriented language?

[ShaunR]

On 10/30/2019 at 9:25 AM, Rolf Kalbermatter said:

So the solution is to replace the Open File, Create File and Create Directory among with some others functions (like Delete File) with my own version that can handle the paths properly. Great idea except that LabVIEW does not document and hence not guarantee how the underlaying file system object is mapped into a file refnum. So in order to be safe here I also have to create the Read File, Write File, Close File, File Size and such functions.All doable but serious work to do.

This is what I deduced for Windows. (It was a while ago, but this is what I recall)

Casting the refnum to an integer reveals the same value as the windows file handle (from Process Hacker). Casting it back enables using the native LabVIEW functions. Casting the handle from CreateFileW to a LabVIEW file refnum also allows usage of all the native file functions(including delete) but the LabVIEW delete function isn't symlink aware (treats it as a normal file). The LabVIEW file functions just seem to be primitives of the windows functions *A (which is what can be seen in the imports table).   <- this is rubbish

It'd be nice if someone from NI confirmed that the file refnum is or isn't just a LabVIEW version of the windows file handle (perhaps with a reference count) but that's all it seems to be. I think it is like the TCP reference in that regard.

Edited October 31, 2019 by ShaunR

[Rolf Kalbermatter]

1 hour ago, ShaunR said:

This is what I deduced for Windows. (It was a while ago, but this is what I recall)

Casting the refnum to an integer reveals the same value as the windows file handle (from Process Hacker). Casting it back enables using the native LabVIEW functions. Casting the handle from CreateFileW to a LabVIEW file refnum also allows usage of all the native file functions(including delete) but the LabVIEW delete function isn't symlink aware (treats it as a normal file). The LabVIEW file functions just seem to be primitives of the windows functions *A (which is what can be seen in the imports table).

It'd be nice if someone from NI confirmed that the file refnum is or isn't just a LabVIEW version of the windows file handle (perhaps with a reference count) but that's all it seems to be. I think it is like the TCP reference in that regard.

Yep I know! Linux is a fileID, except there are at least two different types of identifiers, one is a socket like one and one is a posix file IO one. Mac is nasty. For 32 bit it seemed to be a Carbon API FS number, later changed to the posix file IO number for 64 bit. Not sure they changed anything for 32 bit too. The differences and uncertainities make it not a safe bet to just ASSume things and HOPE it will always remain like this, sorry.

But nooooo, a file refnum is NOT a Windows file handle. Pease repeat after me: IT IS NOT!. You need the file manager function FRefNumToFD() to retrieve the underlaying file descriptor handle.

The File primitives do quite a bit more than just calling the according Windows API function. A lot sits in the path resolution where thinks like shortcuts will autmatically be resolved. It won't do anything special about symlinks and all the Windows APIs except the CreateHandle() with special flags and GetFileAttributes() are made by Microsoft explicitely to work in the way to not do special things with symlinks in the name of maximum backwards compatibility. You need to call special functions to deal with symlinks and some are still not available officially such as reading the target of a symlink explicitly. 

Edited October 30, 2019 by Rolf Kalbermatter

[ShaunR]

11 hours ago, Rolf Kalbermatter said:

But nooooo, a file refnum is NOT a Windows file handle. Pease repeat after me: IT IS NOT!. You need the file manager function FRefNumToFD() to retrieve the underlaying file descriptor handle.

Is that a consequence of using an intermediary DLL and "adapt to type" on the CLFN? Using the type cast at the LabVIEW level should mitigate this for TCP and file refs.

11 hours ago, Rolf Kalbermatter said:

You need to call special functions to deal with symlinks and some are still not available officially such as reading the target of a symlink explicitly. 

Depends on what you want to do with them. Deleting the target? If the LabVIEW delete function is based on deletefile (and I can't remember off hand if it is because it doesn't take a filename), then deleting the target depends on the FILE_FLAG_DELETE_ON_CLOSE when calling createfile. I'll have to go back over this because I figured it out last time with the Zip library but for release, only needed long filename support (and even then, only for extraction). I added the methods to create and read the symlink attribute with a view to adding the functionality later after some bug reports. IIRC writing symlinks wasn't much of a problem, reading them were a little bit harder but shorcuts were a pain which I decided not to do. The file read and write only take a handle and don't care about most of these issues. Of course I haven't concerned myself with Mac and Linux. 

[Rolf Kalbermatter]

6 hours ago, ShaunR said:

Is that a consequence of using an intermediary DLL and "adapt to type" on the CLFN? Using the type cast at the LabVIEW level should mitigate this for TCP and file refs.

Hmmm, maybe LabVIEW learned as some point to do that cast if you pass a file refnum to the pointer sized integer input on a Call Library Node. Never tried that!

[ShaunR]

3 hours ago, Rolf Kalbermatter said:

Hmmm, maybe LabVIEW learned as some point to do that cast if you pass a file refnum to the pointer sized integer input on a Call Library Node. Never tried that!

Hmm. Just looked at my creatfile in the Zip Library. Seems I used "FNewRefNum" rather than a cast so I was obviously talking out of my backside. I guess I remembered all the stuff that didn't work rather than what did.