LabVIEW
Calling subroutines from dll
Wise Owl wrote:
> I am trying to call routines from a vendor supplied dll. They
> helpfully gave me a header file, but little else. The header of the
> subroutine that I'm trying to call reads:
> _LYDYAQCW_API DWORD GetSysVersion(WORD* version, WORD*
> release, WORD* patch, DWORD DriverHandle);
> I interpreted the DWORD as U32, and WORD as U16 with * as "point to
> value". Running the VI causes LabVIEW to disappear instantly with
> not-so-much as a whisper. Can anyone help, with this problem and more
> generally, how to interpret the datatypes in Windows APIs. The one
> document I have found does not have these types.
I would suggest two things. First make sure you wire a constant or
something to the left side of the parameters. A 0 constant would be enoug
h.
Also make sure that _LYDYAQCW_API actually really is defined as
__stdcall among other things. If it is __cdecl instead that would
explain the crash. Especially the underscore in front of the function
makes me suspicious that the function is actually __cdecl.
Second the DriverHandle seems to be an input parameter. So you probably
need to get that from some other function (such as _OpenDriver() or
something similar) first. What could happen in the DLL is that it tries
to reference that handle and since the default value 0 is passed into
the function you get an access violation of some sort.
Rolf Kalbermatter
> I am trying to call routines from a vendor supplied dll. They
> helpfully gave me a header file, but little else. The header of the
> subroutine that I'm trying to call reads:
> _LYDYAQCW_API DWORD GetSysVersion(WORD* version, WORD*
> release, WORD* patch, DWORD DriverHandle);
> I interpreted the DWORD as U32, and WORD as U16 with * as "point to
> value". Running the VI causes LabVIEW to disappear instantly with
> not-so-much as a whisper. Can anyone help, with this problem and more
> generally, how to interpret the datatypes in Windows APIs. The one
> document I have found does not have these types.
I would suggest two things. First make sure you wire a constant or
something to the left side of the parameters. A 0 constant would be enoug
h.
Also make sure that _LYDYAQCW_API actually really is defined as
__stdcall among other things. If it is __cdecl instead that would
explain the crash. Especially the underscore in front of the function
makes me suspicious that the function is actually __cdecl.
Second the DriverHandle seems to be an input parameter. So you probably
need to get that from some other function (such as _OpenDriver() or
something similar) first. What could happen in the DLL is that it tries
to reference that handle and since the default value 0 is passed into
the function you get an access violation of some sort.
Rolf Kalbermatter
Wise Owl wrote:
> Rolf, thanks for your help in this matter. Immediately, by changing
> the calling convention to C, LabVIEW does not crash. There is a
> InitDriver function that it looks like I should call. However, the
> handle is defined by "LPDWORD DriverHandle". Does this not imply that
> the value is passed, making it impossible for the function to pass
> back a handle? Do you have any idea how I can find a lookup table to
> translate LPDWORD, WORD, etc. into LabVIEW specific byte counts?
Well, if you are familiar with C you can look at the Windows SDK headers
to find out what they mean. Most of these basic types are defined in
WinDef.h.
A short explanation
LP stands for Long Pointer meaning a 32 bit pointer (pass as pointer)
P sta
nds for Pointer (meaning the same as LP in modern Windows at least
until we get 64 bit Windows.)
BYTE is an unsigned 8 bit integer
WORD is an unsigned 16 bit integer
DWORD or UINT is an unsigned 32 bit integer
CHAR is a signed 8 bit integer
SHORT a signed 16 bit integer
LONG or INT a signed 32 bit interger
BOOL a boolean (a 32 bit integer in fact)
HANDLE (and almost any type starting with H..) a handle (just treat it
as 32 bit unsigned int)
So in your case the parameter LPDWORD would mean to configure an
unsigned 32 bit integer which should be passed by reference (as pointer).
> Making a call to this function produces an exception which stops the
> Call Library Function Node. Probably because I have the wrong
> variable types defined.
If you configure the parameter to be passed as value (not a pointer)
this would be what should happen.
Rolf Kalbermatter
> Rolf, thanks for your help in this matter. Immediately, by changing
> the calling convention to C, LabVIEW does not crash. There is a
> InitDriver function that it looks like I should call. However, the
> handle is defined by "LPDWORD DriverHandle". Does this not imply that
> the value is passed, making it impossible for the function to pass
> back a handle? Do you have any idea how I can find a lookup table to
> translate LPDWORD, WORD, etc. into LabVIEW specific byte counts?
Well, if you are familiar with C you can look at the Windows SDK headers
to find out what they mean. Most of these basic types are defined in
WinDef.h.
A short explanation
LP stands for Long Pointer meaning a 32 bit pointer (pass as pointer)
P sta
nds for Pointer (meaning the same as LP in modern Windows at least
until we get 64 bit Windows.)
BYTE is an unsigned 8 bit integer
WORD is an unsigned 16 bit integer
DWORD or UINT is an unsigned 32 bit integer
CHAR is a signed 8 bit integer
SHORT a signed 16 bit integer
LONG or INT a signed 32 bit interger
BOOL a boolean (a 32 bit integer in fact)
HANDLE (and almost any type starting with H..) a handle (just treat it
as 32 bit unsigned int)
So in your case the parameter LPDWORD would mean to configure an
unsigned 32 bit integer which should be passed by reference (as pointer).
> Making a call to this function produces an exception which stops the
> Call Library Function Node. Probably because I have the wrong
> variable types defined.
If you configure the parameter to be passed as value (not a pointer)
this would be what should happen.
Rolf Kalbermatter
