Can't create C++ DLL that loads in LV using NI's example

[Southern_Cross]

I'm sure that this is user error but I can't figure out what I've done. 

I'm trying to make a DLL for the first time for many years. I'm following the example NI posted here: http://www.ni.com/tutorial/3056/en/

I have a Windows 10 machine (64-bit). I'm running LabVIEW 2018.0.1F4 (32-bit). I'm using Visual Studio 2010 Professional to create the DLL. I've attached a .zip file with the VS solution, source and asociated VI that calls the DLL. When I configure the CLN in the included example with the proper path to the new DLL that VS builds, I get an error from LV that indicates that the library cannot be found or loaded. I've given the absolute path to the DLL. 

What am I missing? I'm using NI's example code... what detail have I forgotten about authoring C++ DLLs to be used with LV?

Thanks in advance.

[cbutcher]

I'm using Windows 10, LabVIEW 2019 32-bit, and VS Community 2017.

When I opened the solution and built the project, then double clicked on your CLFN and updated the path, it worked fine for me.

Are you sure the path was valid and not being somehow masked or deleted (it loaded in C:/tmp - perhaps it had additional path details like "/debug/blah.dll" instead of just "blah.dll"?)

Try building into a different directory.

Edit:

If I try running the case and get the error list window, I have the following message with 64-bit DLL and 32-bit LabVIEW:

The library specified for this node cannot be found or cannot be loaded. Right-click the Call Library Function node and select Configure, then choose the correct library name or path.

Is that what you're describing? If so, check the bitnesses.

Further comments below, none of which are going to solve your issue...

Spoiler

I also note that you didn't show the values of the SA and Volume calculated, but won't cause the error (the input controls are irrelevant for scalar values, LabVIEW will allocate memory when you set it to use Pointer to Value).

Setting 1 as the return value for everything being good is a little unusual too, but again not the cause of the issue you're seeing.

If I continue to use LV 32-bit and build a 64-bit version of the DLL, I get an error specifying that the bitness is incorrect when I select the path at CLFN, again not the error you're seeing. Just thought I'd check that too (although you said specifically LV 32-bit and your project has no 64-bit target).

[Southern_Cross]

@cbutcher

Thanks for the comments. The bitness has been consistent all along. Turns out that I had forgotten to switch the configuration to RELEASE...

[rolfk]

You forgot to mention that you were trying to execute the DLL on a different computer than your development machine with Visual Studio installed. A debug build will link to a special debug version of the C runtime that is only present on computers with the same Visual C version installed as was used to create the build. 

But even a Release build will link to the Visual C runtime library, which is different for every major Visual Studio version and must be installed on all target systems on which you want to execute that build. The fact that it works on your computer without explicit installation of the Microsoft Visual C runtime library is not surprising as most Windows systems come even out of the box with two or three different Visual C runtime versions pre-installed for various tools and programs that come with it. But there is no guarantee that a Windows system contains a specific C runtime version and you should always make sure to run the redistributable C runtime installer from Microsoft for the Visual Studio version you were using on any new system. In the worst case it will simply exit without doing anything if the runtime or a newer version of it is already installed. But it will make sure it is installed on the system and available for your DLL to be used.

[Southern_Cross]

@rolfk

That is very valuable information! Thank you.

The original posting came from testing NI's example which I reverted to to check my knowledge. 

Now, when trying to compile some existing custom code I find that I cannot use VS 2010 because it appears to use some C++11 code. If I compile with MinGW, and statically link the runtime using: 

-static-libgcc

I'm able to load and run the custom code on Windows just fine. Dependency Walker shows that it only depends on KERNEL32.DLL and MSVCRT.DLL. However, ultimately I need to run this on the cRIO-9082 (Pharlap) target. Trying to download the same VI that works on Windows to the 9082 (after manually downloading my custom DLL and verifying it's path), LabVIEW complains about not being able to find or load the DLL. (I verified the path by using LabVIEW's File System VIs to list the path and file... I then used that path exactly in the CLN.) 

My current speculation is that coming C++11 code with MinGW is linking in some dependencies from the runtime library that NI's flavor of Pharlap does not expose in it's runtime... This is only a speculation though. 

Any advise, other thoughts along these lines? My next step is to see if we can rewrite the custom codes to not use C++11 so I can compile it in VS2010. If successful, the thought is that the DLL will then be able to be loaded on the 9082/Pharlap. This is a bit of a costly/time consuming approach so if there is a better way... I'm all ears!

[rolfk · Accepted solution]

Your suspicion is mostly correct. Except that it most likely has nothing to do with C++11 specifically, but anything with what the static libgcc library expects to be able to link to in msvcrt.dll. This is the Microsoft C Runtime library component that comes with Windows and was used By Visual C compilers until Visual C 6.0 as Runtime component. Microsoft however found it to difficult to maintain forward and backward compatibility with this component for multiple C compiler versions and started to ship each Visual C compiler with its own C runtime library when releasing Visual Studio .Net (2002).

The state of msvcrt.dll as shipped in the Pharlap ETS system is mostly at the level that Windows 2000 had. There are some minor modifications over the different LabVIEW Realtime Versions, partly from updates that came with the ETS system itself as NI incorporated them into the Realtime plarform, partly from small modifications done by NI itself to make it more compatible to certain tools they wanted to include but Windows 2000 is basically the baseline you have to count with when targeting Pharlap ETS. The Pharlap ETS system has been put long ago (around 2012) into maintenance mode by Interval Zero and it is impossible for new customers to buy it. Only existing customers with an active license can still receive documentation and development tools for the last released version but no support anymore.

Your libgcc runtime library most likely was never really targetting Windows 2000 but certainly has received improvements that assume a higher version of the Windows API components. It's even possible that it makes use of semi documented features in msvcrt or other system libraries that are specific to certain Windows versions.

You can use this tool to check the dependencies for your DLL for any particular LabVIEW Realtime version. Most likely it will tell you which APIs your DLL tries to call that are not supported by a particular LabVIEW Realtime version but it is likely that you can not change that since it is called by the standard runtime support included in libgcc. Changing libgcc and convincing gcc (or MinGW) to use this custom version is definitely not something most developers would feel comfortable to do.

NI has ported some of the Visual C runtimes to be installable on the Pharlap systems. But the latest supported Visual Studio version in this way is Visual Studio 2010 and that is not very surprising considering that Pharlap ETS has been basically discontinued by Interval Zero in 2012 in favor of their other product called RTX.