LabVIEW
CIN Core / P4 incompatibility ?
Solved!
Are you sure you are not running LabVIEW for Windows 64 Bit versions on those computers? The CPU should not make any difference for LabVIEW if the CIN is compatible for the current platform, but the bitness of the underlaying OS for sure could mean something here.
In that case what you describe is not only possible, but completely unavoidable. LabVIEW for Windows 64 Bit is just as much a different platform from LabVIEW for Windows 32 Bit as LabVIEW for Linux or LabVIEW for Mac OSX, eventhough they nowadays all run on x86 type CPUs.
Also porting those CINs to DLLs might be a good point now. Because CINs are really legacy and are already not supported on LabVIEW embedded and possibly on the 64 Bit versions of LabVIEW although I'm not sure about this latest point.
Rolf Kalbermatter
Another possibility that I just remember now would be that your cin code makes use of some external library (Visual C runtime would come to my mind since you say you are only using math.h) that is not installed on those machines. Windows XP predates Visual Studio 2008 by far, so it does not come with the Visual C 2008 runtime libraries out of the box.
When you choose to link your Visual C CIN DLL project and select to use the dynamic runtime library Visual C will only link in a stub link library that loads the actual C runtime from the Visual C runtime DLL. However each Visual Studio version comes with a newer version of said library.
That is why when you create a project with a recent Visual Studio version, and you want to make sure your project can be run on any but the hyper duper newest Windows version, you should also distribute the C runtime that comes in the redistributable libraries for said version.
Or as I do, use an older version of Visual Studio. I compile most of my projects (no CINs for several years already however) still with Visual Studio 6, whose runtime libraries were even on old Windows 98 machines. 
Rolf Kalbermatter
@Sci-Vi wrote:
I agree CINs are getting a bit old compared to DLLs, and for many situations I also prefer DLLs. But sometimes CINs are good for two aspects :
- we have mesured a faster execution (2 to 3 times, with same code, same compilation, same hardware - only transformed .DLL to .LSB and call as CIN object) in some very specific circumstances (high rate fast calculation on rather large amount of data). I cannot explain precisely why, but we have measured it...
- distribution of simple single VIs that need to execute some portion of C code can be easier, you don't need to always think about this "little" DLL file that must follow everywhere... Just send the VI by email, copy it anywhere, drop it in your code and it runs. I agree this last point is not so universal, as my question above demonstrates ! Portability definitely is an issue...
Speed differences between CINs and DLLs are most likely because CINs always work with native LabVIEW datatypes, while with DLLs you have the choice to use native datatypes or more common C datatypes for strings and arrays.
When using native datatypes your C code has to be very carful to use LabVIEW memory manager functions whenever it attempts to change anything about the size or whatever of such buffers but there is no overhead at all when passing data from LabVIEW to the C code and back. With C datatypes there is always some overhead when passing data from LabVIEW to C and back but you can work with normal C memory rules (caller always allocates all buffers and callee uses them as needed).
Technically a CIN is also a DLL under Windows 32 Bit, that is wrapped into a LabVIEW resource file and stored inside the VI. Whenever a VI with CIN is loaded into memory, LabVIEW extracts the code resource and writes the embedded DLL into the temproary directory and then loads that as a DLL. The difference with a normal DLL is that each CIN only exports one single entry point that gets called by LabVIEW for the various events such as (un)loading, (un)initilializing, and run.
So the only real benefit of CINs is that the C code resource is indeed not a seperate file as far as the distribution of the code is concerned. This could have been made into a real advantage if it would be possible to load a different CIN code resource into a VI for each platform that LabVIEW can run on, but that has never happened. For me this is in fact a real drawback as I have often external code that should run on multiple platforms. With DLLs/shared libraries this is easily done if you observe a few rules as described in my blog publications under http://expressionflow.com/author/rolfk/
Rolf Kalbermatter
