Re : integration of a DLL through .h and .lib file

[R1M]

Hello,

In our application we use a DLL that is delivered with .h file and a .lib one but not for CVI.

In the past, qith CVI8.1 we applied the procedure in CVI from .h file to generate the .lib file and it was OK.

With new CVI2013 version I made the same twice: once selecting 32bit DLL, creating a MyDLL_32.lib file, and second selecting 64bit DLL, creating a MyDLL_64.lib file.

In CVI project, I've integrated voth .lib and depending on the build settings, the 32 bits or the 64 bits is highlighted.

Everything looks good ate compilation but execution creates a global fatal error as soon as I call any of the functions from this DLL.

I made a minimal project that uses that function and create the error.

The same project recompiled on CVI8.1 is not compatible if I keep the .lib files from CVI2013: I replace the initial one (MyDLL.lib) and it is OK.

How can I investigate in the creation of .lib files from CVI to find the error?

Other change: the PC used for new dev is W7 64 bits while one for CVI8.1 is XP 32 bits.

Regards

[R1M]

I've placed TestMuxDLL project in ftp incoming directory (TestMuxDLL.zip file).

[R1M]

Update early in the morning and the week:

Till now, I kept both .lib files for 32- & 64-bit applications in the project: changing the target, the appropriate .lib were highlighted or grayed.

In a test project, I'ver removed the not used ones and now it compiles and exectutes without error.

What can be reasons for some .lib accepted with the 2 versions and some not accepted?

I hope I'll be able to write all the application for 64-bit but I'm not sure that why it is convenient to have both in the project, selecteing the appropriate target.

do you have advices for that?

Regards

[R1M]

I made a new test: making an .exe in CVI that call directly the function with a fault at exit.

There is no more problem: it seems it is related to creation of .DLL or to calls from TestStand2013.

To be investigated.

[R1M · Accepted solution]

After checks in the .h file for the 3rd-party DLL, the cause of troubles was found: in CVI2013 __GNUC__ is defined while it was not in previous versions and that created issues in function call method (stdcall or cdecl).

=========  initial code =======
#ifdef MUX_EXPORT_DLL
    #ifndef LINUX
        #define _MUXAPI __declspec(dllexport) __stdcall
    #else
        #define _MUXAPI
    #endif    // LINUX
#else
    #ifdef LINUX
        typedef    void    *HANDLE;
        #define _MUXAPI
    #endif
    #ifdef  __BORLANDC__
        #define _MUXAPI __declspec(dllimport) __stdcall
    #endif
    #ifdef _MSC_VER
        #define _MUXAPI
    #endif
    #ifdef _CVI_
        typedef    void    *HANDLE;
        #define _MUXAPI __stdcall
    #endif
    #ifdef __GNUC__
        #define _MUXAPI
    #endif
#endif
========
Changed to
=========  modified code =======

#ifdef MUX_EXPORT_DLL
    #ifndef LINUX
        #define _MUXAPI __declspec(dllexport) __stdcall
    #else
        #define _MUXAPI
    #endif    // LINUX
#else
    #ifdef LINUX
        typedef    void    *HANDLE;
        #define _MUXAPI
    #else
        #if defined  __BORLANDC__
            #define _MUXAPI __declspec(dllimport) __stdcall
        #elif defined _MSC_VER
            #define _MUXAPI
        #elif defined _CVI_
            typedef    void    *HANDLE;
            #define _MUXAPI __stdcall
        #elif defined __GNUC__
            #define _MUXAPI
        #endif
    #endif
#endif
========

Where is documentation for this change? I think there are other application with such .h file where all the #def are not excluding one to the other.

[R1M · Accepted solution]

After checks in the .h file for the 3rd-party DLL, the cause of troubles was found: in CVI2013 __GNUC__ is defined while it was not in previous versions and that created issues in function call method (stdcall or cdecl).

=========  initial code =======
#ifdef MUX_EXPORT_DLL
    #ifndef LINUX
        #define _MUXAPI __declspec(dllexport) __stdcall
    #else
        #define _MUXAPI
    #endif    // LINUX
#else
    #ifdef LINUX
        typedef    void    *HANDLE;
        #define _MUXAPI
    #endif
    #ifdef  __BORLANDC__
        #define _MUXAPI __declspec(dllimport) __stdcall
    #endif
    #ifdef _MSC_VER
        #define _MUXAPI
    #endif
    #ifdef _CVI_
        typedef    void    *HANDLE;
        #define _MUXAPI __stdcall
    #endif
    #ifdef __GNUC__
        #define _MUXAPI
    #endif
#endif
========
Changed to
=========  modified code =======

#ifdef MUX_EXPORT_DLL
    #ifndef LINUX
        #define _MUXAPI __declspec(dllexport) __stdcall
    #else
        #define _MUXAPI
    #endif    // LINUX
#else
    #ifdef LINUX
        typedef    void    *HANDLE;
        #define _MUXAPI
    #else
        #if defined  __BORLANDC__
            #define _MUXAPI __declspec(dllimport) __stdcall
        #elif defined _MSC_VER
            #define _MUXAPI
        #elif defined _CVI_
            typedef    void    *HANDLE;
            #define _MUXAPI __stdcall
        #elif defined __GNUC__
            #define _MUXAPI
        #endif
    #endif
#endif
========

Where is documentation for this change? I think there are other application with such .h file where all the #def are not excluding one to the other.

[JonathanN]

Our documentation currently doesn't mention this predefined macro which is new to CVI 2013. I've created bug issue #474776 to track this request. Sorry for the inconvenience.