LabVIEW
Error Code 1097 Coming in DLL Calling
Solved!
I'm really sorry if you felt I was being harsh to you. Your post did not indicate that you just meant it to be a FYI post and you were not seeking for any advice. But you have also to realize that there are many people who post about 1097 errors, assuming that since LabVIEW is reporting that error it has to be responsible for the error too. A lot like the messenger has to be the cause of the problem! However a 1097 error simply means that the user has not configured the Call Library Node correctly, or the DLL is doing something it is not supposed to do. For Windows DLLs you can usually assume that the latter is not true. So this leaves in most cases only the option about a misconfigured Call Library Node.
Now you will probably say: But it has worked before! Yes it SEEMS to have worked before, but only because of bad luck. The error that is now causing a 1097 error has existed before, it only didn't get caught as diligently by LabVIEW as it does now. This is because the exception handling around a Call Library Node has been significantly improved in newer LabVIEW versions, at the cost of some performance. And a LabVIEW user is free to set the debugging level in the Call Library Node to a lower level and not see that 1097 error anymore, but that does not mean that the error does not exist, it just is less likely to be noticed, because now the only way to notice it is if it happens to destroy vital memory locations that will cause a crash, but if it caused something that can get caugth by the exception handling, it has destroyed some memory that it should not have done, even if that memory happens to be not vital for the normal operation. It could be for instance a data structure in a VI that gets saved at the next saving to disk, and consequently corrupt something in that VI, that may prevent loading the VI later on.
In 95% to 99% of the cases the 1097 error is caused by to small buffers passed to the Call Library Node for output strings and arrays. If the function wants to return a string with 20 characters in such a parameter the LabVIEW VI better allocates a string buffer with at least 21 bytes before it passes that to the function. LabVIEW can't know itself how big such an array or string buffer needs to be so the programmer has to explicitedly allocate it or in newer LabVIEW versions, at least set the minimum size for that parameter in the configuration for that CLN parameter.
And the original post from Frager Fox indicated that if you upgrade to LabVIEW 2009 and see a crash or error it could be that the Call Library Node is configured as C calling convention but really needs to be configured as Winapi calling convention, because before LabVIEW 2009, it contained some heuristic that silently corrected a C calling convention to Winapi, if the function matched a certain pattern. But the opposite is never true. There is no way short of disassembling the function code, to determine if a function requires C calling convention and consequently LabVIEW never has tried that.
Are you happening to run this VI in a 64 Bit version of LabVIEW? Because this VI was explicitedly written LONG ago (I would guess maybe 15 years ago) when 32 Bit was all that LabVIEW ever was running on (and Windows 3.1 which was itself 16 Bit was still very dominant).
For this VI to work under 64 Bit LabVIEW, you need to configure the first paramter as pointer sized Integer, and also configure the return value as such. And now you run into a BIG problem. The dummy refnum used to mimic a Windows Handle is in all versions of LabVIEW only a 32 bit value, so typecasting your pointer sized value to this refnum will truncate the upper 32 bit of the window handle when run under 64 Bit LabVIEW. Basically the entire Window API library has not only to be reviewed to use proper pointer sized parameter wherevever necessary but it needs also a replacement of the windows refnum by a 64 bit integer value.
@rolfk wrote:
And the original post from Frager Fox indicated that if you upgrade to LabVIEW 2009 and see a crash or error it could be that the Call Library Node is configured as C calling convention but really needs to be configured as Winapi calling convention, because before LabVIEW 2009, it contained some heuristic that silently corrected a C calling convention to Winapi, if the function matched a certain pattern. But the opposite is never true. There is no way short of disassembling the function code, to determine if a function requires C calling convention and consequently LabVIEW never has tried that.
Rereading FraggerFoxs original post carefully, I see that he has indeed suggested the opposite, to change WinAPI calling convention to C calling convention, when seeing errors in the Call Library Node that have not appeared before 2009. This is of course not correct. LabVIEW NEVER has silently corrected the Windows API calling convention back to C calling convention, it only did the opposite before LabVIEW 2009 and only in some very specific cases.
And when calling Windows API DLLs, you can assume in 99% of the cases that they use the Windows API calling convention. There are some exceptions but they are rare and far in between.
@Fragger Fox wrote:
From my experiences, whenever I build a dll out of a C code, i MUST keep the calling convention to C rather than WinAPI. The original post was about a dll made out of C code. I have faced several situations where migrating to LV2009 and above from old versions have made LV to crash while using wrong calling conventions for my DLLs made out of C code. For me, a dll made out of C must be set to C calling convention. Please correct me if I am wrong.
rolfk,
The original post was made about C code, and what Billy is doing is calling a windows based api with wrong calling convention. Both are different cases. For the original post which was talking about C structure, my suggestion does not seem to be incorrect, though it does not relate directly with 1094 error, which, as mentioned in the error description, is something related more outside of LabVIEW.
Fragger Fox
There are actually two issues here:
What calling convention to use for a function depends on how the code was compiled. You can specify specific compiler statements in the source code that tell the compiler what calling convention the function should have. If that statement is missing, it will use the calling convention set in the command line parameters to the compiler, and if that command line parameter is missing it will use the compiler default, which for Visual C is actually cdecl. Other compilers likely use the same default too, unless they are embedded compilers, which may use much more exotic calling conventions for performance reasons.
The other issue is that LabVIEW has had some heuristics before 2009 that were analyzing DLL function names and silently correcting a cdecl calling convention to stdcall calling convention if it found a certain pattern in the function name. This silent correction was removed, without adding some according mutation code when loading old VIs into LabVIEW 2009 or later. LabVIEW NEVER corrected a stdcall into cdecl convention since there is no way to detect if a function needs cdecl, other than disassembling the function. Also the detection for stdcall was based on a naming convention for stdcall functions, that is simply a convention introduced by Microsoft. There is no rule that forbids a programmer to name his cdecl compiled function in a similar way, so they removed that silent correction in LabVIEW 2009, as LabVIEW would be otherwise unable to call a cdecl function that happens to match this naming convention.
