LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

CLN function prototypes naming issue

Solved!
Go to solution

Dear Community,

 

Recently I have encountered an issue with Call Library Node (CLN) to call external code inside LabVIEW™.

 

Issue:

  • CLN uses different function prototype signature when calling same function inside LabVIEW 32 Bit and LabVIEW 64 Bit (See pictures below). Because of this specific issue, the transportability of 32 Bit application/vi to 64 Bit and vice versa is not that user friendly. One has to modify the function signature that the loader can load exported function from dll or so correctly.

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:

LV x86 CLN.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

However, inside LabVIEW 64 Bit, the parameter size is not appended behind the function name:

LV x64 CLN.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Question:

  • Is there any other way that such modification to function prototypes can be avoided?
  • Do I need to add some additional flag to compiler while generating dll symbols.

I would really appreciate if someone can provide some additional details on this issue.

 

Best regards

H. Singh

Download All
0 Kudos
Message 1 of 5
(1,175 Views)

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.

Message 2 of 5
(1,168 Views)
Solution
Accepted by topic author H.Jay

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).

Rolf Kalbermatter
My Blog
Message 3 of 5
(1,127 Views)

@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

0 Kudos
Message 4 of 5
(1,105 Views)

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

0 Kudos
Message 5 of 5
(1,102 Views)