Visual programming is gaining more and more visibility outside the the LabVIEW community. In ITWritings blog Tim Anderson draw attention to the fact that multiple visual programming languages have gained public attention lately. These include a visual programming environment Scratch for kids by MIT, Yahoo pipes RSS feed syndication language and Microsoft PopFly online visual programming language for Silverlight.

It seems that visual programming languages are gaining attention in the field of domain specific languages. This is definitely the right route to go as the main stream general purpose programming languages are hard to replace. In addition domain specific languages allow gathering experience on visual programming in general that can later be leveraged on more general purpose language domains.

National Instruments (NI) has been very protective in the field of visual programming. NI owns multiple visual programming related patents and has used this patent portfolio to keep other companies out of the field of visual programming. It’s interesting to see if NI will continue it’s protective policy and sue MIT, Yahoo and Microsoft for patent infringements.

Shared libraries are since about LabVIEW 6 the preferred way for use with external code in LabVIEW. While they 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 most 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 32bit (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.

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 basically since about LabVIEW 6 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 side the use of shared libraries through the Call Library Node has quite a few advantages.

In this article I will try to compare the most important differences between these two thechnologies 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 everybody 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() 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 dynamically 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 32bit 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 the Dev C++ application (http://www.bloodshed.net).

Conclusions

CINs should be considered legacy technology and should preferably 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.

User interface may be the one most important part of your LabVIEW application. It’s the only part of the application the end-user is directly in contact with. Still user interface is often the part of a LabVIEW application developers spend the least time with in the development process. Does LabVIEW make creating decent user interfaces too easy to be ignored in the design phase?

User roles

Let’s concentrate on graphical user interfaces. What should a user interface design process be like? The user interface design shoud start with determinig the different user roles of your application. For example you may need to have a different kind of user interface for the end-users as you do for the administrators.

Views of your user interface

After you have indetified different user roles you should list the main tasks a users in different user roles uses your application. It’s important not to go into too much detail, just concentrate on the most important tasks. The number of main tasks depends on your application. Determine what kind of views do you need in your application to allow users to do these main taks you have identified. You may need multiple different views such as monitoring view and configuration view and visualization view. Depending on your application, these views may be separate parts of a single window, different states of a window or separate windows.

Paper mock-ups

Once you have determined the main views you’ll need in your application you should not hurry to your computer and start coding. Instead you should sit down, take you pen and paper and start drawing mock-ups of your user interface. A mock-up is a model of you user interface. With pen and paper it’s easy and fast to try different variations of component locations. Also the drawing process helps you to concentrate on the important parts and not to go into too much detail too soon. You identified different main tasks the users need to do with your application. Go trough these tasks with your paper mock-ups. If there are major state changes in your views, don’t spare the paper. Try to cover all important views of you application and all important states of different views. Play around, all time consumed in the paper user interface design phase is well spend.

Usability testing

Next you should grap a small group of potential users and show them the user interface mock-ups you have made. Users tend to think differently from what you expect so it’s important to get into direct contact with the potential users. Show them your user interface paper models and ask them to proceed with the important tasks. Don’t help them too much, let them figure out by them-selves what to do, which button to press. Simulate the user interface functionality by showing them different pieces of paper. Use your imagination to find a nice way to simulate your user interface without a computer. Again, don’t go into too much detail, concentrate on the most important parts. If your test users don’t behave the way you would expect them to, ask them what would be the intuitive way for them to proceed with the tasks.

Hand drawn paper user interface models are an excellent tool for the user testing. In computer graphics based user interface models, the tested users tend to concentrate too much on the details and on the lack of polishing. With hand drawn paper models it’s evident that they are only models and users don’t expect them to be polished. Instead they concentrate on the usability and that is exactly what you want to test with them.

Don’t be afraid with the user test phase. You can really often find suitable test persons from your work or from your friends. Testing your user interface doesn’t take a lot of time but you get plenty of valuable feedback. With this feedback you need to go back to your desk and start considering how to make your user interface better, how would it serve your users better.

Conclusions

User interface design is an iterative process. Depending on the complexity of your user interface you may need to iterate the process several times. Only after you are happy with your paper models, you should start working on real front panel implementations. There are many ways of designing user interfaces and this particular process I learnd from useability experts when working on a consumer product project.

Take a look at Jim Kring’s related post on Human Interface Guidelines on his blog Thinking in G.

Scala is my favorite non-visual or text-based programming language. Scala is a functional object-oriented programming language has succeeded to combine almost all features I’d like to see in a programming language except the visual way of coding. Scala compiles to Java Virtual Machine and is fully interoperable with Java code. There was a nice introductory article on Artima a few days ago First Steps to Scala by Bill Venners, Martin Odersky and Lex Spoon. If you are into text-based programming, you should seriously take a look at this article.

In my last virtualization article Streamlined Software Development with Virtualization I discussed about benefits of virtualization and virtual machines on software development process. In this article I present how to set up an excellent free PC virtualization software VMware server to Windows XP host computer and how to install Windows XP client system on it.

Setting up VMware Server

VMware Server is an excellent virtualization software for software development. It’s feature rich, easy to set up and completely free. VMware targets VMware Server for light duty server virtualization and targets non-free VMware Workstation for software developers. VMware Workstation should have some extra features but unless you really need these extra features there is not any need to pay for them.

VMware Server can be downloaded from product homepage. To install the product, you’ll need to gain serial numbers. The serial numbers can be requested from VMware for free by filling-up registration form. Installation of VMware is very straight forward. If you don’t have Microsoft web server IIS installed on your computer, the installer will complain of the lack of IIS. The IIS is only needed if you want to manage your virtual machines over the network and for local only installation you can safely ignore this complain and press Ok to continue.

Creating A New Virtual Machine

After you have installed VMware Server you need to create a new virtual machine. Virtual machine runs on top of host operating system. It uses a large file as file system image, shares the host computer keyboard, mouse, monitor and network connection. To create a new Windows XP virtual machine you’ll need a Windows XP installation CD and a Windows XP license.

Start VMware Server. From an appearing pop-up window select local host to indicate VMware Server that you want to manage the virtual machines on your local computer and not machines on the network. From File menu select New > Virtual Machine. A wizard will start that guides you trough the virtual machine set-up process. After few initial options the first real decision you need to make is to choose the network connection type. Bridged networking is probably the best choice. If you are in a network where each computer needs to be registered for the network, then NAT networking will be easier as you don’t need to register your virtual machine to the network.

The second important choice is selecting the disk capacity. Set the capacity as high as you think you ever may need in this virtual machine, the capacity cannot be increased later on. Uncheck Allocate all disk space now option to keep disk usage at minimum. The disk will be allocated as needed. Finally click Finish button. The virtual machine will be created.

After you have created your new virtual machine you still have to specify the resources it may consume. Click your virtual machine on the inventory unless it is already selected. On the right-hand pane of the VMware Server Window under Commands bar you should have an option link Edit virtual machine settings. Press this link to open the virtual machine settings window.

On the Hardware tab set memory to 512MB if you have 1GB or more of system memory to guarantee Windows XP to run smoothly on the virtual machine. Then click on the CD-ROM settings and turn on the Connect at power on option. This makes your CD/DVD-drive automatically visible to the virtual machine. You need your CD/DVD to be visible so that you can install operating system and software to the virtual machine.

Now we are ready with setting up VMware Server itself. Let’s continue to installing the operating system.

Installing Windows XP on Virtual Machine

Installing windows XP to virtual machine doesn’t much differ from installing Windows to any other computer. Insert the Windows XP installation CD to the CD-ROM drive of your computer. Make sure you have a valid license with a Windows XP serial available. If you have autorun enabled on your host computer, ignore the window that will pop-up.

Make sure you have selected the correct virtual machine from the inventory on VMware Server control panel. Now start your virtual machine by pressing the Start this virtual machine link on the VMware Server control panel. The Virtual Machine should now start up, then connect to your host computer CD-ROM drive and start the Windows XP installer on the CD. From now on the Windows XP installation will proceed as normally.

Installing VMware Tools

After Windows XP installation has finished, there is still one more task to do before you can start using your virtual machine as normally. The virtual machine runs on top of the host computer and the performance is not optimal. All the graphics, mouse movements and key presses are transferred between the host computer and the virtual machine. VMware Tools is a package that should be installed on the newly created virtual machine to improve the performance of the host computer - virtual machine link.

On Windows virtual machines the installation of VMware Tools is very straight forward. On linux virtual machines you will need to recompile your kernel. When virtual machine is turned on and you have logged into it with administrator privileges, select Install VMware Tools from VM menu of the VMware Server control window. This will mount a virtual CD image and if autorun is turned on, an VMware Tools installer will automatically start. If autorun is not turned on, you’ll need to start the installer manually from the CD-ROM drive of your virtual machine.

Conclusions

Congratulations, you’ve now installed VMware Server on Windows XP and installed another installation of Windows XP on the virtual machine. To install applications to virtual machine, simply insert installer CD:s to your host computer CD-ROM drive and you can directly access them from your virtual machine. You can mount CD-ROM images on your host computer to your virtual machine.

It wasn’t that difficult, was it? If you are interested in getting some deeper knowledge on any aspects of virtual machines, please let me know. I can consider writing further articles on using virtual machines on software development.

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 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 interfacing to third party drivers and libraries or that some optimized code 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 16bit and the stack as well as pointers inside the 32bit environment had absolutely no meaning to a DLL running in the 16 bit environment. So when passing information between the 32bit LabVIEW application and the 16bit 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 32bit 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 32bit memory into the 16bit memory and for pointers additional translations need to be done to make the pointers valid in the 16bit 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 32bit 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 32bit <-> 16bit 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, multithreading

With the introduction of multithreading support, the external code interfaces also got somewhat more complex in certain situations. To take advantage of multithreading the external code interfaces needed to get configured to tell LabVIEW if it was safe to call the external code in different threads. For CINs this was done by exporting an additional function from the CIN which told LabVIEW if the CIN was safe for reentrant execution or not. LabVIEW assumed automatically unsafe behavior if this export was missing. This forces the CIN to always be executed in the only exclusively single threaded execution system, which was 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 VI could really know if a function was safe or not, either because he had developed the DLL himself and understood 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 multithreading environment only to find that the application starts to crash or exhibits unexplainable calculating 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 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. This 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 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.

I’m very excited to announce that Rolf Kalbermatter will be blogging a series of articles on LabVIEW external code interface here at EXPRESSIONFLOW. Rolf is a highly appreciated and active member of LabVIEW community. Rolf’s special areas of interest are in LabVIEW related low-level issues such as LabVIEW internals and external code interfacing. As a former employee of National Instruments, Rolf Kalbermatter has had an excellent opportunity to gain a deep insight to these issues. I’m very happy to welcome Rolf as an author at Expressionflow.

Multiple users have reported that they are unable to post comments to Expressionflow. The problem has been tracked down to have been caused by rich text comment editor that was used on this site. The rich text comments have now been disabled and there should be no more problems posting comments. Should you have any problems, please inform me. My email address can be found at the bottom of the page in the copyright notice. (Post has been edited!)