TestStand 64bit version

[dug9000]

---

@R1M wrote:

I made debug and error appears when jumping from closing braket }, after the return instruction.

It is not in our C code...

Our application was operating with Testand3.1 and CVI 8.1. Before any change in the parameter communication, with impacts on all the function, I'd like to get application operate!

Optimization due to new version capabilities are good but main function is the most important to keep, from my point of view.

Regards

---

You said it crashed even when teststand wasn't involved (i.e. when your dll is called from your CVI exe), correct? and it used to work with an older version of CVI? If so then the issue might be with CVI. Can you post the code here, or post code that reproduces the problem in a simple case?

I'll look into if there are any known issues with CVI 2013 that could be related to this.

-Doug

[dug9000]

There are some known issues with CVI 2013 related to struct passing. Have you tried installing the latest patch for CVI 2013 (from the NI Update Service) and recompiling? Also there is a service pack for CVI 2013 that is likely to become available in the near future, so I'd recommend trying that as well once it's available. In the meantime, you might switch to using an older version of CVI in order to get things working if the CVI 2013 patch from update service doesn't resolve this issue.

Please let me know if using either the patch to CVI 2013 or an older version of CVI resolves this issue. Also if you can post a code sample which reproduces the problem I can verify for you whether or not it is caused by a known issue, and if not, I can create a bug report for it.

Thanks,

-Doug

[R1M]

I use CVI13.0.0(647) at the moment in Evaluation version, in order to validate migration from 8.1

At the moment, I'm not able to run my application on new platform, thet is very bad for our customer that NEED Windows7 and this new platform.

Where could I get a previous version of CVI (and Teststand?) that supports my architecture (even if it is not yet 64 bits, only 32 bits)?

[Daniel-E]

Hey R1M,

I'm working with some colleagues here at NI to try and reproduce your issue so we can narrow down the cause. Unfortunately, we haven't yet been able to reproduce the behavior you are describing. Would it be possible for you to create a simple DLL reproducing the issue? I imagine it would just need one function, and it sounds like you actually created a DLL like this for your own testing. If you could post that for us to look at, we would appreciate it. If you aren't comfortable posting it on the public forum, please send me a private message and we can make arrangements for you to send it to me.

Thanks!

[R1M]

Hello,

The situation now focuses on one item, in CVI: I've the 3rd-party DLL in 32- & in 64-bits.

Looking in the DLL components, the 64-bits is a "managed" one while 32-bits is a "non-managed" one.

It is probably why in CVI, called from Teststand or from CVI, the 64-bits version creates a "General fault" at the end.

I'm in touch with the 3rd party support team to work deeper in the issue.

Anyway, I'm not sure CVI make right the job for creating .lib file (from .h & .dll) or calling the functions.

In fact, my issue is not related to Teststand but I keep surprised to see that since 4 years you have not delivered a 64-bits compatible version of this major product: I would prefer my application runs in 64-bits on the associated platform, despite first I want it to work, even in 32-bits.

[R1M]

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.

For the question of CVI compiling with .32 and .64 bits, just changing the target in Build menu, it remains impossible to make 64-bits application with a 32-bit .lib in the projet. May be changed with the SP1 available now but not applicable to evaluation versions 😞