rt - error importing dll

[scarlo]

Hi,

I'm trying to use a dll I wrote on a PXI + RT.

I compiled the dll using visual studio express 2010 on windows vista. Importing and running the dll on labview on my workstation works just fine,

but when I try to load the program on a PXI + RT I get a bad import error.

Using the RT dll checker (version 2009 and 2011) I see I have 25 bad imports from msvcr100.dll and kernel32.dll. Some of the functions I cannot import correctly are:

DecodePointer, DecodePointer, CreateEventW, CreateSemaphore, etc...

I'm new to using dll's in LabView and I'm wondering if I missed something or if I'm doing something wrong...

Can you help me?

Thanks

Carlo

[nathand]

Not all Windows functions are supported in the RT operating system; most likely you are trying to call unsupported functions.  See "How Can I Verify that My DLL is Executable in LabVIEW Real-Time?"

[scarlo]

Thanks for the reply.

I'm not using any windows function in my code.

It is a C code which is stand alone (except for the use of math functions in #include <math.h>).

Do you have any other idea why my dll does not work?

Carlo

[nathand]

But the functions you mention that do not import properly are Windows functions.  If you're not calling them, then they're probably part of the run-time code that the compiler includes.  Perhaps there's some way to tell the compiler to use a smaller version of the run-time library?

EDIT: by the way, sorry for pointing you at an article that you apparently already read.  I missed that you had already run the DLL checker when I first replied to your post.

[rolfk · Accepted solution]

You may not be calling any Windows functions directly but certainly C runtime library functions. And the C runtime library in Visual C is basically build on top of the Windows API. So if your DLL links with the Visual Studio C runtime in any way you pull various imports into your DLL. In fact the imports you listen are mostly located in msvcr100.dll which is the C runtime library. Even if you wouldn't make use of any C runtime function either, Visual C still will pull in C runtime references for its startup code for the DLL.

In normal Windows systems you simply can install the distributable runtime installer for the C runtime library versions that matches with your Visual Studio version, but in the realtime system that is not a real option as each newer runtime depends on similar new Windows APIs. Of course that is NOT intentional (ha!) but simply in the interest of all users as newer Windows APIs automagically mean more security, right?

NI supposedly installs a specially crafted MSVCR DLL that they most likely build themselves to work for the realtime kernel installed on a system but that is based on an older version of the MS C runtime (and I do not want to know what licensing deals with Redmond were required to be allowed to do that, but I'm sure there is a lot of legalize involved there). Basically what this means is, that you have to use the Visual Studio version that is compatible to the MS C runtime library available on the realtime target in order to create shared libraries, Simply check for an msvcrxx.dll in your realtime system and you can see from the xx, what version that needs to be (except that the version numbers are not as trivial to match anymore, but 7.0 was VS 7, 7.1 was VS 2003, 8.0 was VS 2005, 9.0 was VS 2008 and 10.0 was VS 2010). Alternatively you can try to find a Visual Studio 6.0 installation with SP 5 and compile your DLL. This DLL will make use of the Microsoft internal standard C runtime MSVCRT.DLL which avoids the whole versionities at the potential cost of DLL hell troubles.

Another option could be to use some MinGW based compiler toolchain instead. They usually make use of MSVCRT.DLL too for their C runtime linking. Another option is to install the Windows Device Driver Kit or how it is called nowadays. The command line compiler toolchain that comes with it, also links to MSVCRT.DLL instead of a VS specific runtime library.

Trying to trick newer Visual Studio version into using MSVRT.DLL instead is an exercise in vain as I had to find out in many hours spent on this. My current approach is to use VS 6 to create realtime DLLs, since I have it available, but you can't buy it anymore or download it from Microsoft.

[scarlo]

Thanks a lot for your in-depth answer!

Carlo