Don't search for missing DLLs on Mac or Linux (shared objects for other platforms)

[Jim_Kring]

If I am on Mac or Linux and I try to open a VI that calls a DLL inside of a Disabled Structure, then LabVIEW searches for the missing DLL.

This is really a waste of time and effort, since it will never find or be able to load the DLL on Mac.

LabVEIW should be smart enough to know that it's not going to file a *.dll (Windows dynamic linked library) or a *.so (Linux shared object) on a Mac -- Mac uses .framework as it's shared library files.

So, I would extend this a little further and say that LabVIEW should only search for shared libraries of the type for that platform (.framework on Mac, .dll on Windows, .so on Linux).

Note: if a Call Library Function is configured for cross-platform (meaning it's configured for with a "*" file extension like mylibrary.* so that it will find the correct extension on the target platform) then go ahead and search for it.

[rolfk]

Hmmm, you may feel that file endings have a real meaning because Windows generally uses them and even has features totally depending on them, but they are just a convention really. There is no real measure other than convention, that prevents you to call your Windows DLL myLib.framework and try to load it in LabVIEW (or the Windows API) with that name. The opposite is also possible, by naming your Mac shared library with the DLL ending, which I actually have seen in some software being used! The actual Windows core doesn't really care about file endings. Most of the file ending enforcement is located in the shell layer, which is similar to the old Finder on the Mac (shell32 is basically simply a collection of functions that was initially lifted from the File Manager/Explorer executable and added as Windows common API and later extended with IE functionality too). Its architecture is inconsistent at best and sometimes totally confusing, quite contrary to the real Windows kernel in ntdll.dll and friends.

LabVIEW's file type enforcement based on file endings, while not entirely non-existent is VERY weak. That is because it originates from MacOS, where file endings traditionally were simply cosmetic. On MacOS the real file type was and still is represented by meta data stored in the file system resource stream for that file. LabVIEW didn't quite go as far as emulating this behaviour on other platforms but most functions in LabVIEW will not prevent you to treat myVI.something as a VI or other LabVIEW file type either. LabVIEW simply reads the file header and determines if the file is a valid format, independent of any particular file ending or even no ending at all.

So such a change could potentially disable a currently fully working software from executing properly. It certainly should not be implemented by simply skipping any attempt to load a file because its file ending looks wrong. It could be maybe implemented by initially trying to load whatever the function wants to load and on failure simply skipping the search operation but even that is potentially disturbing existing workflows.

And that search dialog has two buttons called "Ignore Item" and "Ignore All". Try them, especially the second and you are a happy camper again!