Questions about C language DLL's and executable supported in LabView Real Time

[TeslaCoil]

I have a PXI crate running Labview RT, and we are hoping to create some DLL's using C  that our LabView application make function calls to at run time. It is important for us that whatever Development environment we choose to develop the C code, will be able to build  a DLL  compatible with Labview RT.

My questions are: 

1. Will it be safe to assume that if I use Labwindows to compile some C code that those Dll's will be compatible with Labview RT running in a PXI crate?

2. Could using MS Visual Studio along with MEasurement studio allow me to compile some C code in to DLL's, and those Dll's will be compatible with Labview RT?

3. Anything else I should take in to consideration?

Disclaimer: I am t a Labview newbie and this is my first time in the forums.

Thanks in advance!

-T

[rolfk]

1) Yes that should work. But make sure with NI support about the versions. Each CVI version has it's own runtime version and not every Pharlap ETS version from NI comes with support for every possible CVI version.

2) Yes that works, sort of. You are likely to run into C runtime version difficulties however. NI installs some Visual C runtime libraries into the RT system for their own use (LabVIEW is compiled in Visual Studio too, among other components, and no CVI can't compile LabVIEW as the whole LabVIEW source is C++ by now).

You can't install the standard Microsoft C runtime redistributables on the ETS system, since that goes nowadays VERY deep into the Windows kernel and calls functions that Pharlap ETS never will provide. Instead NI ported the C runtime library from Visual C to their RT platform and installs that onto the controller. Obviously that runtime library is compatible to the Visual Studio version used to create the distribution and that is in fact an older version. Unless you use the same version of Visual Studio your are likely running into problems with missing exports from the C runtime for your compiled DLL. Even if you don't call any fancy C runtime functions, the Visual C linker likes to pull in low level functions for the startup stub that is linked to each DLL. This does fancy things like exception handling initialization and much more, even if you don't use any exceptions in your code. And this has traditionally changed with every Visual C major version.

Linking in the C runtime library statically can help to solve that problem a little but as mentioned before the startup stub that gets also linked in likes to do some low level calls during initialization and some of those are simply not available on ETS. Because of all these troubles I personally I still use Visual Studio 6 to create RT DLLs.

One other way to get around these C runtime versionities troubles would be supposedly to use the MS command line compiler from the Windows DDKs. This compiler supports (or at least did in previous versions) linking in startup stub support libraries that are compatible back to W2000 and only depends on the standard MS C runtime library msvcrt.dll. All Visual C compilers after Visual Studio 6 will automatically link with their own version of msvcrtXX.dll and any attempt to convince them to do otherwise usually results in a non-executable DLL.

3) I think the first 2 points are already enough to worry about! But check out this link. The executables in their are a good first test to see if your resulting DLL wants to pull in Windows API functions that are not compatible with the particular ETS system. As long as you have any bad functions in there you are definitely not good to go. Stub functions may work if your code path doesn't hit them, or doesn't rely on information from them.

[TeslaCoil]

Thanks for all the good information, how about if I wanted to create an executable in MS VS, should I take anything in to consideration to get an executable that will be compatble with LabView RT?

[rolfk]

Basically the same limitations apply.