Importing Functions from a Shared Library File, Built-In Example Question

[MJK48]

I went through the Built-In LabVIEW example for importing a shared library file described here:

Example: Importing Functions from a Shared Library File - NI

I followed the steps laid out, but something I'd like to understand is why the DWTest_Unsupported () function doesn't work with the wizard. 

I see that the wizard tries to give helpful hints such as including "stdio.h", "NIAPI_stdcall = __stdcall", "NIAPIDefined = 1",  etc, but I can't seem to get that function to successfully work. 

Under the Configure Include Paths and Preprocessor Definitions, I've included:

Include Paths:

C:\Program Files (x86)\Windows Kits\10\Include\10.0.26100.0\ucrt

Preprocessor Definitions:

stdio.h; NIAPI_stdcall = __stdcall; NIAPIDefined = 1; vcruntime.h

My current issue is that I can't seem to find a path to a vcruntime.h file on my computer. I feel as though I'm just going down a rabbit hole I shouldn't be.

Is there a simple explanation as to why the DWTest_Unsupported () function won't convert? I don't have a strong background in C languages, if that's not obvious.

[Kyle97330]

".h" files in C is often where definitions of data types are stored.  If one is missing, and not "standard" enough for LabVIEW to have it included, LabVIEW can't know how to pack up a set of bytes to send to a DLL function call (or use to unpack the return value) and have it not crash or return garbage.

If everything works but one function, that's usually because that one function has either a parameter or a return type of a data type located in a ".h" file that you are missing, and the rest of the functions either use standard data types or data types defined in ".h" files that you did include already.

You could try to find a stray copy of it out there and see if adding it works.  There's one here from 11 years ago:

https://github.com/icestudent/vc-19-changes/blob/master/vcruntime.h

[rolfk · Accepted solution]

If you had attached the header file that defines the DWTest_Unsupported() function we may have been able to tell you a little more. Without that we can only tell you that the recommendations that the Library Wizard gave you are very generic, simply mentioning some of the more common of about a zillion possible things that may be a problem.

With C programmers generally being very handy about inventing all kinds of datatypes, special preprocessor defines, aliases and what else, any even halfway complete list of things would likely fill a PDF file with several 1000 pages and would be completely useless too, as nobody would find the actually correct piece in there, if it was even present.

Now having a computer available to look at the actual code the function in question has this prototoype void DWTest_Unsupported() and the problem is the definition of size_t that the wizard doesn't properly understand. You can add a definition to the Proprocessor Definition in the "Configure include Paths and Preprocessor Definitions" page in the wizard like:

size_t=unsigned long

This lets the wizard compile the function but it does not do the correct thing. In one of the the next dialogs "Configure VIs and Controls" you need to redefine the parameters for that function:

But you are not yet finished! To really be correct independent of if you run this in 32-bit or 64-bit LabVIEW you will have to open the diagram of DWTest_Unsupported.vi and go into the Call Library Node to reconfigure the datatype of the inputTest and outputTest variable. Change the Data type from Unsigned 64-bit Integer to Unsigned Pointer-sized variable for both of these parameters. Et voila, you are done.

But how in Gods name does anyone know that? Well, DLL interfacing is C programming and without a solid C programming knowledge trying to interface to DLLs is basically playing roulette in guessing things. There are a few things the wizard could do better such as recognizing the <stdint.h> (C99) datatypes properly, which size_t is one of them, but the problem with the import library wizard is that it seems like a nice feature, except that it can't possibly recognize many specific things from the header declaration alone, so you end up with a suboptimal solution anyhow even if the wizard was perfect. The only way to really make for a DLL a wrapper library that is guaranteed to not crash the first time you try to call it and also not the millionth time you call it is by having a programmer with real C programming knowledge review and in 99% of the cases revise the generated wrapper library anyhow! And then test it and test it again and stress test it even more until it absolutely doesn't crash anymore!

Hoping to invoke the import library wizard and just get a usable wrapper library that you can give to just about any LabVIEW programmer is a pipe dream and always will remain that.