Any runtime issues with using CVI 8.1.1 runtime engine with Labwindows 7.1.1

[JonathanN]

Hi Ryan,

As menchar mentioned, Windows does use a specific algorithm to search for DLLs on your system.  This is an important concept to grasp when trying to understand versions of DLLs loaded by executables.

For starters, let’s suppose that you have installed CVI 8.1 on your system.  This means that you will have the CVI 8.1 IDE and the CVI 8.1 RTE (in the system32 directory) installed.   As a result of this, any CVI executable (no matter where it’s run from; i.e. from within the IDE or outside of the IDE) will always be using the CVI 8.1 RTE.  Even if you have multiple versions of CVI installed (7.0, 7.1, 8.0, etc), all CVI executables on that system will target the CVI 8.1 RTE. 

Now, let’s suppose that you happen to copy all the CVI RTE files to the same directory as the CVI executable. When this executable is run, it will use the CVI RTE that is in that same directory because it’s the first location Windows searches for a needed DLL. If you are curious about this, you can use Process Explorer which allows you to peek inside a process and see which DLLs are loaded into memory as well as their locations.

As far as distribution changes and issues, as of CVI 8.0 and later, the run-time engine that ships with your distribution is the one that is installed on your system. So this means that the RTE packaged with your distribution matches the one that it was tested against on your development computer.  In the past (CVI 7.1 and earlier) this was not the case.  Each version of CVI on the system would include the RTE that shipped with it. This meant that you could be developing a CVI 6.0 app, testing it against the CVI 7.1 RTE installed on the machine, and then distributing the application with the 6.0 RTE. This in turn could cause your application to behave differently which is why we change this behavior in CVI 8.0 and later. 

Hope this helps!

Best Regards,

[majo0008]

Jonathan, Thanks for the info. I'll check out the process explorer utility. We only have Labwindows/CVI 7.1 installed but the CVI run-time engine in the system32 directory was automatically updated to 8.1 when I installed the latest version of NI-VISA. It sounds like I do need to be careful about this and make sure that I always put the 7.1 run-time engine in my application directory during development. I appreciate yours as wel as menchar's support.

-Ryan

[LuisG]

Hello Ryan,

I wanted to follow up on this thread in case you had any more information about the errors that you started seeing when your application began using the CVI 8.1 runtime engine. Our expectation is always that upgrading the runtime engine should have no effect on an existing CVI application, yet it sounds like that's not what happened with you. So, if you do have more information, and you don't mind the hassle, we'd like to try to get to the bottom of that.

Thanks,

Luis
NI

[majo0008]

Hi Luis,

My original problem was due to the fact that I had a version 7.1.1.134 cvirte.dll file in my project directory and version 8.1.xxx runtime engine in my system32 directory. I DID NOT have the other runtime engine files as well as the cvirte folder in my project directory. The problem was that when I went to debug an application the cvirte.dll and the cvirte folder were not the same version and thus I was seeing some strange behavior on my development system. After I put the full run-time engine into my project directory everything worked just fine using either 8.1.xxx or 7.1.1.134 runtime engine.  I did not do a real thorough test on this but my strange problems did not reappear regardless of engine version.

We always use distribution kits and put the full runtiime engine in the application directory upon install however we were a little careless on our development systems. In order to make sure we use the correct run-time engine during debugging and development we NOW put the desired run-time engine files into our project directory as well. This is the directory that contains the debug version of the executable.

Now one thing that is on my to do list is to try to run two different applications at the same time where each application has a different run-time engine version and see if this causes any problems. Can two different versions of the run-time engine run simultaneously? Also (as was suggested earlier) if I run an application using a newer run-time engine, close this application, and run another application that has an older version of the run-time engine in its directory, which runtime engine will be called up? Hopefully the one present in the application directory as one would expect. I'll hopefully run this little test soon and will post the result.

-Ryan

[LuisG]

Thanks for the explanation, Ryan. That makes sense.

To answer your questions:

When you build an application using a specific version of the CVI environment, that application does not require a specific version of the CVI run-time engine. The only requirement is that when it runs, that it can find a version of the CVI run-time engine whose version is equal or higher than the version of CVI which built the application. Therefore, it is possible to build an application with CVI 7.1, for example, and then run that application using the CVI 8.0 run-time engine. So when you ask about running two applications simultaneously, each of which has a different run-time version, I should clarify that there's nothing inherent in the application that specifies the run-time version. It will run with whatever it finds (as long as it's not too old).

Having said that, it is possible that two separate applications end up each using a different run-time engine when they run. That happens when one or both of the applications has a "private" run-time engine installed in its application directory. (I'm oversimplifying things quite a bit here, because many CVI libraries in turn use other resources, that are themselves installed globally, even if the core CVI run-time engine is installed locally). In this scenario, you can certainly run both applications simultaneously. It's even okay, if one or both apps is a DLL, and they both end up loaded in the same process.

Finally, to answer your last question, each application will search for a run-time engine to use without regard to what you might have run previously. So in the scenario you describe, it will definitely continue to use the run-time engine in your application directory.

Luis