Rolf Kalbermatter

I recently came across a posting that seems to be rather popular and reposted quite frequently on Facebook and other social sites.

It usually starts with a reference to Einstein, who was frequently asked if he believes in God and his answer was usually similar to this:

“I believe in Spinoza’s God, who reveals himself in the lawful harmony of the world, not in a God who concerns himself with the fate and the doings of mankind.”

Einstein, around 1920

After this, following quote is usually attributed to Spinoza himself:

God would have said:

“Stop praying and giving yourselves blows on your chest. What I want you to do is to go out into the world and enjoy your life.

I want you to sing, have fun and enjoy everything I’ve made for you.

Stop going into those gloomy, dark and cold temples that you built yourself and that you call my home. My house is in the mountains, in the forests, the rivers, the lakes, the beaches. That’s where I live and express all my love for you.

Stop blaming me for your miserable life. I never told you there was anything wrong with you or that you were a sinner.

Stop reading alleged sacred scriptures that have nothing to do with me. If you can’t read me in a sunrise, in a landscape, in the look of your friends, in your son’s eyes… you will find me in no book!

Stop being so scared. I do not judge you, nor criticize you, nor am I ever angry with you, nothing bothers me, nor do I devise punishment. I am pure love.

Stop asking for forgiveness, there’s nothing to forgive. If I made you, I filled you with passions, limitations, pleasures, feelings, needs, inconsistencies of free will, how can I blame you if you respond to something I put in you? How can I punish you for being as you are, if I’m the one who made you?

Do you think I could create a place to burn all my children who misbehave, for the rest of eternity? What kind of God can do that?

Forget about any kind of commandments, of any kind of laws; those are wiles to manipulate you, to control you and only to create guilt in you.

Respect your peers and don’t do to others what you don’t want for yourself. All I ask is that you pay attention in your life, that your alert status is your guide.

Life is not a test, not a step on the way, not a rehearsal, nor a prelude to paradise. This life is the only thing there is, here and now and the only thing you need.

I have made you absolutely free, there are no prizes or punishments, no sins or virtues either, no one carries a marker, and no one keeps a record. You are absolutely free to create in your life a heaven or hell.

I couldn’t tell you if there’s anything after this life, but I can give you a tip. Live as if there wasn’t. As if this was your only chance to enjoy, to love, to exist.

So, if there is nothing after, then you will have enjoyed the opportunity I gave you. And if there is, rest assured that I won’t ask you if you behaved well or wrong, I will ask you: Did you like it? Did you have fun? What did you enjoy the most? What did you learn?

Stop believing in me; believe is to assume, guess, imagine. I don’t want you to believe in me, I want you to feel me in you when you kiss your beloved, when you play with your little girl, when you love your dog, when you bathe in the sea.

Stop praising me. What kind of egotistical God do you think I am? I’m bored of your praise, I’m tired being thanked.

Do you feel grateful? Prove it by taking care of yourself, your health, your relationships, and the world around you. Do you feel overwhelmed? Express your joy! That’s the way to praise me.

Stop complicating things and repeating as a parakeet what you’ve been taught about me. The only thing sure is that you are here, that you are alive, that this world is full of wonders.

What do you need more miracles for? Why so many explanations?

Don’t look for me outside, you won’t find me. Find me inside… there I’m beating in you.

That’s my substance, dear Humans. That’s the Substance of God!”

Attributed to Spinoza by some

I was certainly moved by this text and it resonated in many ways. But was this really from Spinoza and why haven’t I read about this before?

But it is not so easy to find good references. While the way God is portrayed here certainly has many similarities to how Spinoza saw God as something immanent and described it “as only one substance, which is absolutely infinite, self-caused and eternal”, it is also written in a way that is very contrary for someone who considered God to be not a person or entity but something that not only permeates the entire universe but in fact is the universe and possibly more and is at the same time without cause and reason.

And the earliest references to this text that I could find seem to be around September 2019.

This link seems to be from September 5, 2019 and has the name of Baruch De Spinoza underneath, so seems to attribute it to himself.

This link seems to be from September 13, 2019 and is more written in a way to indicate that this text would be what Spinoza might have said what God would say if he would be a self aware entity.

There are other more recent versions and also a discussion on Quora if this text is really from Spinoza. The consensus seems to be that while it in some ways could be a very loose translation of something that Spinoza has said at some point, it certainly isn’t a very accurate transcript of anything that Spinoza ever published and likely neither wrote in some private correspondence with someone. He would likely have agreed with the idea that God is not someone or something that keeps a scoreboard or something, but he might as well have taken issue with the idea that God could even have said something like that as he did not see God as a person who would talk or have opinions.

LabVIEW being a multiplatform development system has a few handy and neat features that allow more easily to write one single VI library to interface to the different types of shared libraries on the the different platforms.

Shared libraries come in various forms depending on the platform they are build for. On Windows they use the well known .dll extension, under Linux and most other Unix versions they have the .so extension and on MacOS X they use the .framework extension for a so called bundle, and .dylib for the binary loadable module. A bundle is in reality a directory with various subdirectories that contain version resource files as well as (potentially) multiple version of the actual binary shared library and that can even consist of different binary shared libraries for multiple architectures. So can a bundle contain both a 32-bit x86 shared library as well as a 64-bit x64 shared library and also an ARM64 shared library. The shared library loader will then automatically reference the correct one, depending on the architecture of the current platform and the calling application. As far as the Graphical Shell of MacOS X is concerned it will not show a bundle as a directory in which one could browse into but instead simply represent it as an object.

But all this is only a MacOS X feature. All other systems on which LabVIEW can run, do not have such an automatic multi architecture bundle system. Linux uses something else called multiarch, which is similar to the way Windows handles the difference between 32-bit and 64-bit binary compiled code. It maintains different directories for each bitness and the shared module loader will search in the according directories that match the bitness of the application requesting to load a certain library. But this only works for shared libraries that are installed in this OS folders. And there still remains the issue that the actual shared library is called mylibrary.dll under Windows, while it should be called mylibrary.so under Linux and mylibrary.framework for MacOS X.

The LabVIEW Call Library Node supports a handy feature for a very long time already. This is present at least as far back as LabVIEW 7. If one enters as library name simply mylibrary.*, LabVIEW will automatically replace the asterix after the dot with the default ending for the platform it is running on. So if you write some shared library that you want to call from LabVIEW, and make sure to keep the function interfaces the same on every platform, you can simply give it on all platforms the same file name with the according file ending and then write one single VI library to call the different functions and use the same VI library on different platforms. Of course since around LabVIEW 8.6 the Call Library Node also allows to pass a path from the diagram, which can be computed at runtime by building the correct library name and passing that to the Call Library Node. This works too, but the use of simply one single name in the Call Library Node itself is potentially much easier to maintain (as long as you don’t decide to change the name of the shared library later on for some reason).

Platform	Ending	Example	Result
Windows	.dll	myLibrary.*	myLibrary.dll
Linux	.so	myLibrary.*	myLibrary.so
MacOS X	.framework	myLibrary.*	myLibrary.framework
Pharlap	.dll	myLibrary.*	myLibrary.dll
VxWorks	.out	myLibrary.*	myLibrary.out
NI Linux RT	.so	myLibrary.*	myLibrary.so

Different shared libraries for 32-bit and 64-bit

With LabVIEW 2009, LabVIEW for Windows was the first version to also run as 64-bit application. But that gives some extra problems. While Microsoft did add some support for loading 16-bit DLLs into a 32-bit process, they never got very happy with that. It was cumbersome to use, very hard to get right and very difficult to support properly. They were careful to avoid these problems this time, by simply not letting a 64-bit process load a 32-bit DLL. With some serious assembly code it would be of course possible. But who in his right mind wants to do assembly programming nowaday? Microsoft simply said, no it can’t be done and that was it. There was some initial complaining of people who wanted to take shortcuts by not having to compile their shared libraries for 64-bit and push the burden on the users of their shared library, but pretty soon everybody had accepted that it simply can’t be done and started the process of recompiling and often rewriting their software for 64-bit. Only cleanly developed and written code was easy to port, and many who had thought they had been very careful and only written absolutely clean code, discovered now that their code wasn’t quite as clean and actually contained many assumptions that only worked for 32-bit compilation.

But how can a LabVIEW VI be written, so that it can call the correct shared library no matter if the VI is executed in the 32-bit or 64-bit version of LabVIEW? We don’t necessarily want to have to resort to the Conditional Compile structure to place two or more almost identical Call Library Nodes in every VI that wants to call a shared library. If the shared library is installed in the system, the OS takes care about that by maintaining different directories for the two architectures and loading only from the one that applies to the process demanding to load a shared library. But if that shared library is application private, for instance alongside the VIs that call it, things are not so simple. The OS doesn’t know which directory would be for which architecture, if there are even separated directories.

The LabVIEW developers chose to extend the earlier used wildcard system a little more. This is actually also documented in the online help to the Call Library Node since around LabVIEW 2011 or so, but who is reading manuals anyways? 🙂

If the library name contains an asterix before the point indicating the start of the file ending, this asterix is replaced by LabVIEW with the number “32” if it is running in LabVIEW 32-bit and with “64” if it is running in LabVIEW 64-bit and the resulting name is used to try to load the shared library. If there are two consequent asterix’ in the filename, LabVIEW will replace them with an empty string in LabVIEW 32-bit and with “_64” in LabVIEW 64-bit.

Filename	resulting 32-bit filename	resulting 64-bit filename
myLibrary*.dll	myLibrary32.dll	myLibrary64.dll
myLibrary**.dll	myLibrary.dll	myLibrary_64.dll
my*Library.dll	my32Library.dll	my64Library.dll
my**Library.dll	myLibrary.dll	my_64Library.dll

With these little tricks it is fairly easy to write LabVIEW VI libraries that do not need Conditional Compile structures or other platform specific wizardry in the diagram and can still call external shared libraries on different platform without requiring any changes to the VI code.

LabVIEW 2014 added support for 64-bit applications to Linux and MacOS X versions and uses the same wildcard technique on these platforms too. LabVIEW 2016 was the last version on Linux and MacOS X to be possible to install as 32-bit version. On Linux and MacOS X, LabVIEW is 64-bit only since 2017. While it may still be available as 32-bit version on Windows for maybe one or two more years, this is ultimately going to be discontinued at some point too, and I would expect this to be not in a far future.

This is an old post that has appeared on expressionflow.com on May 19, 2007

Shared libraries are since about LabVIEW 6 the preferred way for use with external code in LabVIEW. While the Call Library Node can directly interface with many existing shared libraries for the platforms LabVIEW supports, they can also be used to interface to shared libraries that were specifically developed for use with LabVIEW. And one of the very neat features of LabVIEW itself is its multi-platform support. This multi-platform support can even be taken to external shared libraries that were specifically developed for use with LabVIEW. If one observes a few rules and makes smart use of some not very well documented facts and features of the Call Library Node, this will result in a very easily maintainable solution both in terms of the C code as well as the LabVIEW VI libraries.

Calling convention

One aspect of shared libraries is, that on some platforms, each function can have different so called calling conventions. A calling convention is a specification how parameters are to be passed to the function. This usually happens over the stack but some not very common calling conventions also can use registers for all or the first x number of parameters. For instance under Windows 3.1 the two most common calling conventions were Pascal and C. The difference between them is that Pascal passes the parameters on the stack from right to left while C passes them in the opposite order. A second difference is that with Pascal the called function is responsible for restoring the stack just before returning to the caller while in C the caller is restoring the stack itself after the function returns. Under Windows 32-bit (9x, ME, NT, 2000, XP) the two most common calling conventions are ’stdcall’ and C. The difference here is only in who is cleaning up the stack as the order of the parameters is really the same in both. In any case having a caller assume a different calling convention than what the called function is implemented in, will always cause a stack corruption and end in the General Protection nirvana, or if implemented in the exception handler, immediately after return of the function to the caller.

While different platforms support different calling conventions, the only common one on all LabVIEW platforms is the C calling convention. This is an important thing to consider when one wants to create multi platform shared libraries. By making sure all exported functions in the shared library use the C calling convention one only needs to maintain one single VI library for all possible LabVIEW platforms.

Library name

Each platform has its own type of naming convention for shared libraries. Under Windows all standard shared libraries use a .dll extension, while under modern Unix systems using ELF shared libraries this is usually the .so extension. Power Macintosh shared libraries normally have a .framework extension.

One handy and not well documented feature in the LabVIEW Call Library Node is the fact that one can simply specify the shared library name as “<name>.*” and LabVIEW will automatically search the directory containing the VI as well as its search paths for a shared library file consisting of the <name> part together with the appropriate extension for the current platform.

So by defining the name of the shared library in all Call Library Nodes as “mylib.*” for instance, you can truly have one single VI library that interfaces on all LabVIEW platforms to the correct shared library. You can even put all those shared libraries into the same directory and LabVIEW will pick the right one. Unfortunately this does not work for Macintosh systems since a shared library there is really a collection of files in a subdirectory and some of these files make use of the resource fork, which gets lost if these files are copied to a non Macintosh file system.

LabVIEW manager function use

A common misconception is that only CINs can make use of the LabVIEW manager functions documented in the External Code Reference Manual. This is absolutely not true. A shared library can just as easily call any exported LabVIEW manager function such as NumericArrayResize() to create LabVIEW compatible data types, which eventually even can be passed back to LabVIEW to be used on the diagram unaltered. To be able to do that, your shared library only needs to include the extcode.h and possibly the hosttype.h file in the cintools directory and link with the labview.lib file in that same directory. The only limitations are that the functionality of those LabVIEW manager functions really is provided by the LabVIEW development environment or runtime system. Therefore a shared library linking to any of those functions will only be executable (in fact loadable) in the LabVIEW development environment or in a LabVIEW executable. But this can hardly be considered a disadvantage, as CINs by nature only can run in those environments.

Use of these LabVIEW manager functions can make your C code a lot more uniform across platforms. These functions are provided by LabVIEW on all platforms in the same way, and are guaranteed to have the same semantics and behaviour. This can greatly reduce the number of places in your source code where you would otherwise have to provide specific code parts for the different platforms or compiler tool chains.

Conclusion

Knowing the details about the previous three sections one can create a single VI library interfacing to the appropriate shared library for the platform, LabVIEW is currently running on. We will see this in one of the upcoming articles in this series.

This is an old post that has appeared on expressionflow.com on May 19, 2007

Not looking at ActiveX and .Net, since they both are Windows technologies only and are not really suited to integrate generic external code into LabVIEW, there remain two similar possibilities nowadays to integrate external code into LabVIEW. These are CINs and shared libraries through use of the Call Library Node. While CINs used to have certain advantages over shared libraries in the past, this is since about LabVIEW 6 basically not true anymore and with LabVIEW 8.20 the Call Library Node got additional features that remove the last (esoteric) advantages CINs had over shared libraries. On the other hand however have shared libraries quite a few advantages.

In this article I will try to compare the most important differences between these two technologies and try to make a point, why anyone should nowadays go for the Call Library Node with shared libraries, instead of using CINs.

Let’s start with two features where CINs still had a slight advantage over shared libraries until the advent of LabVIEW 8.20. The previously mentioned “callback” functions introduced in LabVIEW 8.20 actually make the Call Library Node go on par with CINs in these aspects. I will investigate into the specifics of those callback functions in a later article in this series.

Advantages of CINs before LabVIEW 8.20

Instance specific data storage

One advantage of CINs used to be the possibility of instance specific global data storage. If you don’t know what this could be and why you could use it, you most probably never will need it and you can skip this section.

Using the functions GetDSStorage() and SetDSStorage() one can use a single 4 byte location which LabVIEW manages on a per instance base. This means that unlike a global variable declared outside any function body in the CIN code, each instance of a CIN in a diagram using that particular CIN code resource gets its own 4 byte value, managed by LabVIEW. You could see this similar to an uninitialized shift register in a LabVIEW VI, which has been set to be reentrant. While this feature could be powerful in some esoteric situations it is almost never used and its understanding is made even more complex by the fact that such a CIN located in a reentrant VI itself, will actually maintain multiple instance specific data storages for each instance of that reentrant VI multiplied by the number of those CIN code resources located inside that VI. Once you continue this acrobatic brain exercise to include multiple levels of reentrant VIs, everything gets very soon very complicated for anybody not used to think in parallel realities in n-dimensional systems.

More detailed control over initializing and unintializing of the code resource

While shared libraries only support initializing and unintializing of code on loading and unloading of the library through OS provided mechanisms such as DLLMain() in Windows or init() and fini()  see footnote 1) under ELF shared libraries, LabVIEW CINs separate these actions into load, init, uninit, and unload together with a save operation. The load and unload is called once for each CIN code resource and could be used to initialize and deallocate global data while the init and uninit is called once for each code resource instance and can be used to initialize and deallocate above mentioned instance specific data storage. The save routine doesn’t really make much sense for someone outside of NI as one needs to know about some undocumented parts in LabVIEW to properly make use of this.

Both these features are very rarely used and can be achieved through other means such as maintaining a pointer in the calling VI inside a shift register and passing this pointer to the function on every call, or by using the platform specific shared library initialization and deinitialization methods in a smart way.

But shared libraries have a number of advantages, which should make it easy for anybody to choose for them instead of trying to dig into the proprietary CIN technology.

Advantages of the use of the Call Library Node over CINs

Parameter type support

With the new Adapt to Type parameter configuration since LabVIEW 5.1, a Call Library Node can pass any LabVIEW data type directly to a shared library without any translation or fiddling around. In this aspect the parameter support is now superior to CINs, since the Call Library Function supports some additional configuration options as well, such as passing LabVIEW handles by reference whereas a CIN will always pass them by value. And the Call Library Node supports also other data types such as C string pointers or C arrays among others and LabVIEW will take care to pass the correct part of its own data type to the shared library so that the library can work on them with the standard C runtime routines. While it is not necessary to use these types for your own libraries, it is an additional bonus which can sometimes be very handy.

– Accessing most shared libraries directly

With CINs you always have to write some intermediate C code to access already existing shared libraries. The Call Library Node can however interface with many shared libraries directly, making the creation of an intermediate wrapper DLL in many cases an optional step. This does not always work that way, since LabVIEW arrays and strings are really dynamically resizeable while most standard C datatypes do not allow for easy dynamic resizable pointers. In a later article I will go into more depths about when you would need to create a wrapper for use with the Call Library Node, but in general many shared libraries can be interfaced directly without an intermediate wrapper shared library.

Multiplattform support

With the current LabVIEW platforms, there is no reason, why maintaining a shared library source code for multiple platforms would be more difficult, than doing the same for a CIN. On the other side if you take care to follow some recommendations in respect to calling and naming convention, mentioned in the next article, there is no reason why you would need one set of VIs for each platform you want to support. For CINs this is mandatory and can only be sort of circumvented with a technique invented by Christophe Salzmann, which he called FatCIN. With this technique you create a VI for each platform you want to support and then you create another wrapper VI, which uses dynamic calls through VI server to load and execute the appropriate VI for the current platform. But this is a rather cumbersome technique, as it will still require one VI for each platform for every CIN and an additional wrapper VI. Also the maintenance of the CIN VI itself will be cumbersome too, since whenever you make a change to the CIN code no matter how small it is, you have to manually touch each platform VI to reload the new code resource.

Multifunction support

If you happen to have a number of functions to support, you can implement them all in a single shared library and create one VI for each function in that shared library. If you are using CINs instead, you either have to incorporate all the functions into a single CIN and create a CIN which takes a selector parameter for the function to execute. This VI also will require a more or less involved parameter list, to support the most extended list of parameters of all the functions. Or you can create a CIN for each of those functions and wonder why a single change to some common parameter type will have you compile each of the source codes separately and then require you to go into each CIN (and in case of multiplatform support into each of those platform VIs too) and reload the code resource into the CIN. In the case of separate CINs for each function you also don’t have any means to store some global information inside the CIN to allow sharing that information among multiple functions.

For shared libraries you almost have to create a VI for each shared library function. But even when using the single CIN approach you still will also usually want to create one additional wrapper VI for every function selector value. This is because direct use of the single selector based CIN VI is not very user friendly. Imagine the many VI parameters on such a selector based CIN that will not have any effect for most of the selected functions.

Compiler tools support

Shared libraries can be created in virtually any development environment which is able to create them. There is no need to use a specific C compiler unless you want to link with the labview.lib library to make use of the LabVIEW manager functions documented in the External Code Reference Manual. This limitation is because object libraries can come in a number of file formats and each compiler has its own preferred object file format and often no support for object file formats from other compilers. LabVIEW for Windows 32-bit comes with a labview.lib file in COFF format, which is the format used by Microsoft Visual C and a labview.sym.lib file in the OMF format used by the now discontinued Symantec C compiler. Borland C also uses some form of OMF format, but it is not clear to me if the Symantec C provided library is compatible with any version of Borland C, because object file formats can and will certainly come in various flavors.

As long as you do not want to link to labview.lib however, there is really no limitation in what development environment you use to create a shared library, provided this development environment can create shared libraries usable by other development environments such as Visual Basic, Delphi or similar.

CINs on the other hand always will have to link to at least cin(.sym).lib and lvsb(.sym).lib and in most cases labview(.sym).lib too and therefore will always be limited to the LabVIEW supported compiler tool chains.

In fact Open source tool chains such as the GNU C Compiler can be used on all current platforms to create shared libraries callable by the Call Library Node, although for Windows I would recommend the use of some customized GNU tool chain such as the MingW compiler tool chain http://www.mingw.org, possibly in connection with a development environment such as Dev C++  http://www.bloodshed.net, or Code::Blocks http://www.codeblocks.org

Conclusions

CINs should be considered legacy technology and should absolutely not be used for new developments. CINs have basically not one single advantage anymore over the use of the Call Library Node but quite a few disadvantages, especially in terms of code maintenance both for the C code as well as for the LabVIEW part! This is already true since about LabVIEW 6.

To see where the future of CINs most probably will go you only have to investigate a current LabVIEW installation and try to find stock VIs, which still make use of CINs. They are virtually non-existent. National Instruments has ported all their LabVIEW interfaces such as NI-DAQ, NI-IMAQ, NI-CAN, etc and add-on tools like the Advanced Analysis library or IMAQ Vision to use shared libraries instead of CINs.

Note from March 2, 2017: Recent versions of LabVIEW have no support to create CINs anymore. While some of them can still execute CINs created for earlier versions, it’s cumbersome at best to create new CINs, as one would need to get the tools from an old LabVIEW installation to do so. And all new LabVIEW platforms such as the Windows and Mac OS X 64-bit versions, or the NI Linux Realtime versions, never received support for creating CINs at all. So CINs are definitely a legacy technology, which is only supported on a fraction of the currently available LabVIEW platforms.

1. init() and fini() are considered obsolete in modern shared libraries. Instead the GCC attributes __attribute__((constructor)) and __attribute__((destructor)) should be used.

This is an old post that has appeared on expressionflow.com on May 9, 2007

From the beginning, the LabVIEW developers recognized the need for some form of node or interface to allow LabVIEW users linking in their own code that could be created outside of LabVIEW. The reasons for wanting this can be varied. Someone might be interested to interface to an existing application or code library already developed and tested in order to leverage its functionality. Other reasons could be about interfacing to third party drivers and libraries or some optimized code, which needs to be executed for performance reasons.
This first installment about external code in LabVIEW will try to bring a historical overview about the possibilities to interface to external code in the different LabVIEW versions.

LabVIEW 2, MacOS only, external code resources

This version of LabVIEW did only run on Macintosh computers. In the Macintosh 68k OS, executable code was really just another resource inside the resource fork of the file among the other resources such as icons, images, menus, text strings etc. LabVIEW therefore used this technology to implement an external code interface. The compiled object code was added to the LabVIEW VI simply as a code resource in addition to the code resource created by LabVIEW from its diagram code. Whenever the VI got loaded into memory the compiled VI code resource and the additional external code resources were linked into the existing code base.

LabVIEW 3, CINs, complications and reasons

LabVIEW 3 (we leave out 2.5 as that was only really a 3.0 prerelease) was the first version to support other operating systems than Macintosh OS. It is not fully clear to me if shared library support was already standard in the Sun OS (later to be called Solaris 1) operating system at that time. The first versions of shared library support under Unix were however in general quite buggy and each Unix vendor had his own ideas about how it should work. The Macintosh OS also did not have a standard interface for shared libraries. One had to download an extension for this and the first version for shared library support was at some point discontinued and replaced by a different incompatible version. Here too, were a number of nasty bugs present that got only slowly ironed out with new releases.
But the most difficult platform was the DLL interface for the Windows version. It had some serious troubles due to the fact that LabVIEW was a flat 32bit memory application built around a so called DOS memory extender. This DOS memory extender was delivered with the Watcom C development system and provided to applications a true 32bit environment while running on top of the old 16bit environment used in Windows 3.x. Any applications wanting to use that environment had to be compiled with Watcom C. This posed problems when wanting to call normal Windows DLLs, since they were really 16-bit and the stack as well as pointers inside the 32-bit environment had absolutely no meaning to a DLL running in the 16-bit environment. So when passing information between the 32-bit LabVIEW application and the 16-bit OS environment the entire parameter stack and any pointers had to be properly translated.
Interfacing to Windows DLLs directly would have meant to translate auto magically every single parameter between the 32-bit LabVIEW environment and the 16-bit Windows memory model. For every single call, a complete new stack frame needs to be allocated in the 16-bit environment, parameters need to be copied from the 32-bit memory into the 16-bit memory and for pointers additional translations need to be done to make the pointers valid in the 16-bit environment. On return of the function these operations have to be reversed too. Watcom did provide some routines to deal with this translation, which basically was only possible by executing some involved assembly code internally, but the setup and configuration of those functions was a quite involved task. Therefore it was decided that this would be a to large development effort for an initial multi platform LabVIEW version. Instead the already existing idea of external code resources from the Macintosh OS was used and ported to the Windows and Sun OS. A Windows CIN back then was in fact a native Watcom REX object code file and a Macintosh OS CIN was a 68k object code file. The lvsbutil tool provided in the cintools directory wrapped this object code file into a CIN header and added the resulting file as another resource to the VI resources. This allowed LabVIEW to directly call the code resource in the same environment as LabVIEW itself was running, without involved memory translations that are difficult to handle automatically and also cause performance degradation. The disadvantage was that the Windows CINs only could be generated by the Watcom C compiler since they needed to be in the 32-bit REX object format, which no other compiler could generate.
I feel personally that the developers missed an opportunity here, when they did not allow for multiple code resources being added for the same CIN. This made it necessary to manually load the correct platform specific code resource into the VI whenever a VI was moved between platforms. This deficiency was never fixed in later versions of LabVIEW and caused a significant loss of convenience in using CINs for multiplatform libraries.

LabVIEW 4, Shared library support

LabVIEW 4 added the Call Library Node to interface directly to external shared libraries (Macintosh Code Fragment Manager components which were not standard for non PowerMac computers, Unix shared libraries and Windows Dynamically Loaded Libraries)
Due to the limitations of the Macintosh Code Fragments and Windows 3.1 16-bit DLLs, the supported data types were limited. For instance function return values other than void and numeric were not possible because of differences how Borland and Microsoft DLLs returned pointer types as function return values. More complex function parameters than string and arrays were also not possible because the parameters needed to be prepared accordingly for Windows 3.1 DLLs. To create an automatic thunking interface supporting more complex data types would have been a real nightmare to implement and therefore was left for a possible later version of LabVIEW. Because of the 32-bit <-> 16-bit translation in accessing external DLLs under Windows 3.1, this solution also had a lower performance than using CINs. Also developing code for more than one platform was not very straightforward when using DLLs. This made the use of CINs still the preferred external code solution in those days, especially when support for multiple LabVIEW platforms was desired or performance was an important issue.

LabVIEW 5, multi-threading

With the introduction of multi-threading support, the external code interfaces also got somewhat more complex in certain situations. To take advantage of multi-threading, the external code interfaces need to get configured to tell LabVIEW if it is safe to call the external code in different threads. For CINs, this was done by exporting an additional function from the CIN which tells LabVIEW if the CIN is safe for reentrant execution or not. LabVIEW assumed automatically unsafe behavior if this export is missing. This forces the CIN to always be executed in the only exclusively single threaded execution system, which is the UI system. For DLLs, there was no way to have an automatic way of telling LabVIEW, if a DLL function was safe for reentrant execution or not. Also a DLL could have multiple functions and some could be safe, while others could be unsafe and Microsoft never had anticipated that a programming environment might be interested in this information from shared libraries. Therefore a manual configuration option was added to the Call Library Node configuration dialog. Only the developer of the shared library can really know if a function is safe or not. The LabVIEW VI developer has to decide if he wants to set the Call Library Node to be able to call the function in any thread or force it to run inside the UI system, either because he has developed the DLL himself and understands the issues, or because he got this information from the documentation for the DLL. In many cases there is no specific information available in the documentation and in that case the best option is to leave the Call Library Node configuration to execute in the UI system. The alternative is trial and error, which can be cumbersome. Race conditions and other errors resulting from unsafe reentrant execution can occur randomly and at different moments, based on previous execution order of library functions. Also many external factors such as system load or used memory can cause randomness in how race conditions make themselves noticed. Often you can execute an unsafe function countless times from a multi-threading environment only to find that the application starts to crash or exhibits unexplained calculation results after it has been shipped to the other side of the world.

LabVIEW 6, Extended shared library support

In LabVIEW 5.1 support for 68k Macintosh and Windows 3.1 was dropped and this allowed for an enhanced data type support in the Call Library Node. A function now could return also a string and function parameters could be configured to adapt to the LabVIEW data type, as no complicated automatic thunking needed to be performed anymore.
In LabVIEW 6.0 this was even more extended with ActiveX datatypes for Windows platforms, additional selections for the Adapt to Datatype parameter selection and as a gadget, the selection of the available function names inside the shared library in a drop down box, but unfortunately only for Windows. Another nice feature added is the Create .c file selection in the context popup menu for the Call Library Node. With this you can let LabVIEW create a C header file with the correct prototype for the currently configured Call Library Node. This feature is especially handy if you happen to use the Adapt to Type parameter type, as LabVIEW obviously knows best how its own data types are to be declared in C syntax.

One indication that CINs are starting to be considered legacy technology by the LabVIEW developers, is the removal of support for creating external subroutines. These were external code fragments not loaded into the VI itself but instead being left as independent files on the file system, in order to be called by different CIN code resources. One of its applications were common subroutines, another one was providing a place to store global data among multiple CIN code resources. This was a fairly seldom used feature although the National Instruments NI-DAQ library and the LabVIEW Advanced Analysis library did make use of them before they were ported to shared libraries that were accessed through the Call Library Node interface.

LabVIEW 7, not much news on this front

LabVIEW 7 has not made significant changes to the possibilities of incorporating external code in comparison to the previous versions. The Call Library Node is quite mature and works well for almost any possible scenario and the CIN support has been further marginalized by removing almost any use of it in all the different LabVIEW function libraries provided by a fresh installation. Also National Instruments finished the port of almost all its hardware interface libraries and add-on toolkits to use the Call Library Node instead of CINs.

LabVIEW 8, A few more improvements

In LabVIEW 8.0 the Call Library Node was left mostly alone and no new feature was added. LabVIEW 8.2 however improved the Call Library Node further by adding error terminals to it, allowing passing the path to the shared library to be loaded at runtime, and it also added so called callback functions although this naming is in my opinion quite misplaced. Callback functions are usually function pointers that a caller can provide to be called back by a library or other external component. This callback functions can usually be called by that library at any time it wants to inform the caller about something. What LabVIEW 8.2 really supports is the configuration of initializing and deinitializing functions that the LabVIEW environment will call before and after calling the actual function itself and an abort function when the user aborts the user hierarchy while LabVIEW is in the process of calling that Call Library Node. Obviously this is only something that is possible for functions that are declared reentrant in the configuration.

LabVIEW 2009, 64-bit support

LabVIEW 2009 is the first version that officially shipped also as 64-bit version, albeit only for Windows for now (64-bit versions for Linux and Mac OS X were introduced with LabVIEW 2014, together with support for NI Linux Realtime for x86 and ARM realtime targets from National Instruments). Accordingly when running in the LabVIEW 64-bit version, all shared libraries that need to be called, have to be compiled as 64-bit library too. The Call Library Node got for that a new numeric datatype which is pointer sized. On the LabVIEW diagram this is always a 64-bit integer but when being passed to the shared library function, LabVIEW will perform the correct coercion to a 32-bit or 64-bit pointer value.