Vendor provided dll doesn't work with LabVIEW 2011, but does for 2010 & 2009

[rrsquez]

Hello, below is some code that calls a dll file (cannot included). This code worked in LabVIEW 2010 and 2009, but not in the 2011.

Using another vendors compiled code, I am able to access this dll, so this dll is not the failure. I have several other PC where this application works. The only difference for the one that does not work is that I'm using LabVIEW 2011. Previoulsy I only had the 2010 version of the Run-Time-Engine installed: My 2010 compiled application worked with no changes. Once I installed LabVIEW 2011, it stopped working. At this point, even the previously mentioned "Exectuable Code" would no longer work.

I found a work-around for the distributed .exe applications: Change the file properties so that the file is "Windows 95 Compatible". This fixed the executable, but I still can't run the Development Environment this way.

The error I get is that the "Com Port" does not open (value should read as "3f8", but reads as "0" instead). My vi runs to completion, but is not able to communicate with the DLL file. Not having the hardware, I cannot expect anybody to troubleshoot this code.

This the dll file (serial.dll) came from Maxim Integrated Products, so it can be trusted. I couldn't include it here because the install file is too big. I got from a support for their MAX1452 chip.

Earlier I tried setting the "Compatibility Mode" of LabVIEW.exe itself, but this did not help (it caused the program to fail to launch).

I believe the "work-around", mentioned above, is the clue to problem with this version of LabVIEW. This new version of LabVIEW is not compatible with the DLL file that I'm trying to communiate with. I cannot understand why, but I know there is a causal link to LabVIEW.

Any ideas would be greatly appreciated.

Best regards, Richard V

[PackersFan]

I seem to remember hearing that the way LabVIEW handled or coerced calling conventions changed in LabVIEW 2011.

Are you certain that you are using the correct calling convention (c v. WinAPI)?  Have you tried the other one?

When troubleshooting dll calls it's always a good idea to set the Call Library Function Node to Maximum Error Checking.

[rolfk]

PackersFan is most likely right. I'm not 100% positive as to which LabVIEW version, but before LabVIEW tried to detect the calling convention of a DLL by looking at the function name. stdcall (WINAPI) functions CAN have an appending that starts with an @ and then has a number indicating the number of bytes that are passed over the stack. This could look like a good idea to help the programmer avoid errors, but there is nobody that has made a rule that a programmer couldn't create a DLL with cdecl convention and explicitedly use a naming convention that looks like stdcall. With such autodetection there is no way someone could incorporate such a DLL into LabVIEW. Also it is in fact an undocumented and and sneaky feature. So in LabVIEW 2011 they removed that sneaky autocorrection and that causes wrongly configured DLLs that worked before to suddenly crash.

This problem only happens if a DLL uses these naming decorations AND the VI programmer in his ignorance set the calling convention to cdecl and assumed that since nothing crashed it was all fine. It's really a programmer fault that was hidden in the past by a feature in LabVIEW that someone seemed to have added without thinking it entirely through.

I do think that there should have been a feature in the mutate code that upgrades LabVIEW VIs to newer versions, that does actually detect such Call Library Nodes and converts the calling convention explicitedly to the previously used, but LabVIEw 2011 is released and it makes little sense to moan about spilled beans.