Simple DLL crash

[R]

I have a DLL problem...

LabView 6i (running under Windows NT) closes down with an explanation of "Application error has occurred" from "Dr. Watson for Windows NT".

The LabView program is very simple, It has a three 16-bit unsigned integer constants feeding a Library Function and one 16-bit unsigned integer indicator. This Library Function has the Function Prototype

unsigned short int setup(unsigned short int board, unsigned short int ownaddress, unsigned short int sclk);

listed in the Call Library Function window and is set to "C" calling convention and "Run in UI thread".

This library (cali2c32.dll) is a commercial product driving an I2C PC card (Calibre PCI93) and comes with a second file (cali2c32.h) for use in C programming which i
ncludes the prototype

extern __declspec(dllimport) int WINAPI setup (int, int, int);

which, as far as I am aware, agrees well with the prototype reported by LabView above. So what could be causing LabView to crash? As you might guess, I'm quite new to LabView, but have some experience with C language. Any help, suggestions or comments would be very welcome.

Richard.

[wxfield]

Richard,

I think I see your problem. You have defined your entry point as a "C" calling convention, when the DLL is expecting a WINAPI calling convention (__stdcall). Try changing that, and you might have better results.
Try checking that you are passing the ints by value, not by reference.

Kindest regards,
Warren

[Greg_McKaskle2]

> I think I see your problem. You have defined your entry point as a
> "C" calling convention, when the DLL is expecting a WINAPI calling
> convention (__stdcall). Try changing that, and you might have better
> results.
> Try checking that you are passing the ints by value, not by
> reference.
>

This is the key element causing the crash. The call will probably work
after making this change alone, because windows will pass the unsigned
shorts as 32 bit values anyway. It would be better to go ahead and
change each of the values in the prototype to be int32s. Int used to
mean 16 bit integer in Win31, but today, with 32 bit OSes, always use
32 bit integers when you see int.

Greg McKaskle

[R]

Greg,

Thanks for your background to this problem. As you may know. The problem is now sorted.

Regards, Richard.

[R]

Warren,

Many thanks for your suggestions. It was the WINAPI calling convention (__stdcall) that caused my problem. All works now. It's satisfying to have such issues resolved so quickly.

Thanks again, Richard.

[AIR]

Richard,

The return value is no "short int" but an "int", in LabVIEW this should be a
I32 or a U32 (either, should both work ok, but I32 is preferable because the
return value could be negative).

If this doesn't help, try the "stdcall" in stead of "C". I'm no expert in C,
but it could be a compiler option to build a winapi...

Hope it helps,

Wiebe.


"R" wrote in message
news:506500000008000000DD2A0000-999158726000@exchange.ni.com...
> I have a DLL problem...
>
> LabView 6i (running under Windows NT) closes down with an explanation
> of "Application error has occurred" from "Dr. Watson for Windows NT".
>
> The LabView program is very simple, It has a three 16-bit unsigned
> integer constants feeding a Library Function and one 16-bit unsigned
> integer indicator
. This Library Function has the Function Prototype
>
> unsigned short int setup(unsigned short int board, unsigned short
> int ownaddress, unsigned short int sclk);
>
> listed in the Call Library Function window and is set to "C" calling
> convention and "Run in UI thread".
>
> This library (cali2c32.dll) is a commercial product driving an I2C PC
> card (Calibre PCI93) and comes with a second file (cali2c32.h) for use
> in C programming which includes the prototype
>
> extern __declspec(dllimport) int WINAPI setup (int, int, int);
>
> which, as far as I am aware, agrees well with the prototype reported
> by LabView above. So what could be causing LabView to crash? As you
> might guess, I'm quite new to LabView, but have some experience with C
> language. Any help, suggestions or comments would be very welcome.
>
> Richard.