LabVIEW
Disk Drive Info (on a Mac)
@paul_a_cardinale wrote:
@MaSta wrote:
This doesn't seem to be one of the VIs from the repository of a LabVIEW installation, because one VI is missing when I open it.
Given, that somebody private has created this VI, the change is low to have this for Mac, because you can assume that only very little people use a Mac for LabVIEW.
Suggestion and workaround: modify the VI to a suitable MacOS DLL and function doing perhaps the exact same thing, given that LabVIEW for Mac has this DLL call node at all.
There are no DLLs on a Mac.
Indeed! It's called shared libraries on Unix and in the case of Mac OS, they actually call it framework or bundles. That are collections of files packed together in a directory hierarchy (that the Mac OS Finder displays as a single file). The advantage of this is that you can actually create bundles that contain the correct binary shared file for each of the possible platform. Theoretically a bundle could support PPC, x86, x64 and ARM64 all in one single bundle. Practically that would be kind of hard as there is no single C compiler that could reliably create shared libraries for all these 4 platforms in the same compiler version, and mixing and matching compiled products from different compiler versions is asking for trouble.
The problem with calling system functions on the Mac is that while there are certain frameworks such as the Carbon framework that provide a standard C calling interface that can directly be interfaced to from the Call Library Node, much of the Carbon framework has been depreciated and sometimes outright obsoleted. The native way of calling system functions is through the Cocoa application layer, and almost all of that is through an Objective C interface. Objective C is a sort of preprocessor object management layer that translated originally things into a rather involved and hard to read C code that is then compiled by the standard C compiler. Nowadays most Mac OS compilers directly translate from the Objective C source code into the underlaying machine code. The fact remains that the Objective C based APIs are in fact also C based APIs and it is actually possible to call them directly from C code (and hence also from the Call Library Node) but doing so is making things very involved as you as programmer are basically implementing the object management layer of Objective C all by hand. A little more effort and you could also start to directly program in assembly!!!
But for relatively simple Objective C APIs it would be definitely possible to call them through the LabVIEW Call Library Node. But that is definitely not fun unless you like to tinker with low level things and run a few zillion times through the program, run, crash, edit cycle!
However for this specific use case there might be a different route. The glibc library also provides many functions for file system management and since LabVIEW for Macintosh 64-bit uses also the Unix file paths rather than the Macintosh Finder paths, you can pass a LabVIEW path (after conversion to a platform string) directly to these functions too.
statfs() and statfs64() in glibc would be most likely returning almost all of the information you are interested in and then some more.
The Linux glibc also provides these functions but the structure in the second parameter is not the same, so a MacOS X implementation could not be used directly on Linux, but would need to be programmed separately in a conditional compile structure.
