Visual Studio C++ library in LabWindows

[mpb]

Hi,

I have a fairly complex function written in C++ and I would like to call it from a labWindows/CVI module. I  use VisualStudio 2005. Is the easiest way (I do not want to translate the code in C!) to "create an import library" using the "options" tab of the labWindows/CVI development environment? How do I then tell where to search for the original "Dll" file? I managed to build the "DLL import library" with LabWindows, successfully created the LabWindows dynamic link library, but with TestStand (calling a function defined in labWindows which in turn calls the function in the VisualStudio DLL) I get a run-time error " complaining that TestStand can not load the LabWindows DLL as it does not know where the required VisualStudio DLL is ...

Thanks

Marco

[mpb]

Well, an even more interesting question: can function declared in STATIC libraries be called from labWindows? Being a static library self-contained, it is less likely to present dependencies issues. Unfortunately I have not found any document discussing static libraries (always DLLs).

Thanks

Marco

[msaxon]

Static libraries are generally not self-contained, they normally have to be linked to the run-time support libraries appropriate to the development platform. So a static library built in VC will require the VC support libraries, a library built in CVI will require the CVI support libraries. Usually these run-times are not compatible, so you will not be able to link a static library built in VC into an application built with CVI.

CVI, being a C language environment, will not interface directly to code written in C++. If you want to use a DLL built with VC++ in CVI, the interface functions must have a "C" format interface, i.e. the functions must be declared extern "C". There are rules about which folders Windows will look in to find a DLL at run-time (which I don't remember off-hand) but it is 'usual' to put application-specific DLLs in the same folder as the executable.

[mpb]

Thanks for your reply!

I am starting to think that maybe the quickest way was to translate the C++ into C...

Thanks

Marco

[msaxon]

It can be easier to translate into C, but if the code uses C++ features (like object orientation) heavily it won't be. Writing a C layer to interface C++ code is a chore but is generally not difficult.

[mpb]

The exporting of C++ functions (avoid name mangling etc.) is not the difficult part. I am not a very expert Visual Studio / LabWindows / Windows programmer, so I always end up spending a loooong time finding all the bits and pieces that need to be provided to have all work together. For example, now I have solved the linking etc problems (I can build the labWindows dynamic library, TestStand finds it and find the Viosual Studio DLL) but TestStand complains about MSVCP80D.dll (not found), which should be part of the Visual Studio runtime, which I had just installed on my system ...

And about C++ conversion to C ... well these few lines of C++ code uses all possible OO specific construct that C++ has. I was even starting to consider writing the vector stdlibrary routines, then I saw a heavy use of template classes and there I stopped!

Thanks again

Marco

[myle00]

The reason why it's complaining about MSVCP80D is that you're compiling the debug version of the code and distributing that. Normally, you release the release version of the compiled project and also provide the VC distributables which comes with you MSVC++ compiler or you can get from MS website. This provides all the system libraries you need to run the dll on a target system. However, if you release the debug version of the dll you won't be able to load it outside the development environment because the MSVCP80D dlls are not distributed in the MS distributables (hence the D at the end of the filename, you'll have to copy them from your sys32 folder to the target system, but they are copyrighted).

However, because the reasleese version is very optimized, you might want to be confidant that your code works well and the compiler won't introduce bugs in the release version that wasn't in the debug version (mostly relevant if this is a multithreaded dll).

[mpb]

Thanks for your reply!

I have now tried with the release version but I still get "can not load DLL", this time without more "obvious" errors about DLLs not found. I have for now given up trying to createa DLL, and I am compiling an executable (statically linked) and passing arguments to and stdout from the executable to be processed by TestStand. This is an acceptable (temporary? I will see) solution as I have really no more time to dedicate to this issue, unfortunately.

Thanks very much, your help was very appreciated. When / if I have time, I think the best would be to "translate" to C.

Marco