01-28-2022 10:31 AM - edited 01-28-2022 10:41 AM
Dear Community,
Recently I have encountered an issue with Call Library Node (CLN) to call external code inside LabVIEW™.
Issue:
As an example I have created a simple dll that exports only one function. When I call the exported function AddInt inside LabVIEW 32 Bit and LabVIEW 64 Bit, I get two different function prototypes. My dll export only one function as below:
// Add two number
extern "C" __declspec(dllexport)
int __stdcall AddInt(int val1, int val2)
{
return val1 + val2 ;
}
Inside LabVIEW 32 Bit, the parameter size is appended behind the function name:
However, inside LabVIEW 64 Bit, the parameter size is not appended behind the function name:
Question:
I would really appreciate if someone can provide some additional details on this issue.
Best regards
H. Singh
Solved! Go to Solution.
01-28-2022 06:19 PM
I create separate 32bit and 64bit dlls and use a conditional disable structure (Symbol : TARGET_BITNESS) to use whatever is correct for the current LabVIEW instance.
01-30-2022 06:32 PM - edited 01-30-2022 06:39 PM
The appended parameter size is a feature of the __stdcall calling convention. It is something Microsoft compilers actually always make for such functions and NI follows that lead (I'm not even sure if it would be valid to force the linker to suppress that decoration).
The LabVIEW Call Library Node should be able to deal with that. When you enter the name without that decoration, it still will call the according function.
But there is also another solution. Configure the function to use the __cdecl calling convention. In this case functions are not really decorated (well sometimes they can be with a prepended underscore, don't you like those pesky C compiler developers?) but anyways LabVIEW is actually actively trying to link to a name with an underscore even if you only enter the undecorated name, if it can't find the name as you have entered it.
And the Windows 64-bit platform neither uses the __stdcall nor __cdecl calling convention, but instead always (well for user space software at least) __fastcall, just to make it more funny. LabVIEW on 64-bit doesn't let you choose a calling convention at all as it always will use __fastcall.
And Windows 3.x in a long long ago time used __pascal and __cdecl. (and Microsoft C and Borland C couldn't agree on certain things such as how return floating point values from a function, which was the main reason that the LabVIEW Call Library Node did not support that back then).
01-31-2022 03:00 AM
@rolfk
Well this explains it all. With __cdecl I get what I expect.
I used __stdcall because the LabVIEW application runs only on Windows and windows does use __stdcall convention for all Win32 services.
Best Regards,
H Singh
01-31-2022 03:05 AM
Condition disable structure does allow to add some switches to LabVIEW Block diagram that are checked at compile time. However, one still needs to add two prototypes for 32 and 64 bit LabVIEW.
Best Regards,
H Singh