LabVIEW
Are there any tips or guidlines when creating DLLs for a Destop RT target (using Visual Studio C++)
AnthonV wrote:Hi, what are the pitfalls or best practices when creating DLLs for a LabVIEW RT target (using a desktop PC). One that comes to mind is not to make any OS calls in the DLL, but are there any other tips (like what are the best build settings are to use etc)?
Any help will be appreciated.
Actually Win32 API calls are not all that bad. The ETS Pharlap RT OS Kernel used supports quite a few Win32 APIs though you should refrain from APIs added in Windows XP and later for sure. There are other APIs that make little sense on an RT system or are simply to hard to implement. On the NI site is a RT module checker to whom you can give a DLL and it will tell you if it uses any APIs that are not supported.
A much more difficult thing to handle nowadays is in fact the choice of your C runtime library. If you choose to link your DLL with the DLL based C runtime, you can run into problems with the C runtime usedon the RT target. The whole NI software is created with a particular C runtime, and I'm not sure if they adopt something to the sources of the C runtime to build it for the RT target but it would seem quite likely that the C runtime DLL is not exactly the same as the one that comes with the Visual Studio system runtime installer.
Especially the newest C runtime DLLs from recent Visual Studio versions are likely not directly executable on the ETS system. You should either link the C runtime statically or make sure you use the same Visual Studio version that was used by NI. I think if you would use VS 2003 you should be safe. I myself use still VS6 for most development work and it seems to still work. 🙂
Rolf Kalbermatter
