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

[majo0008]

We use Labwindows 7.1.1 for development. After upgrading one our systems with NI-Visa 4.1, the CVI runtime engine (in the system32 directory) was updated to version 8.1.0xxx. I checked this by looking at the version number of the runtime engine files in the system32 directory. Now when we are debugging our applications through the CVI environment which run-time engines are being used? The run-time engine in the system32 directory(8.1.0) or 7.1.1? If I make a distribution kit and install on a different system, the 7.1.1 run-time engine files are put in the application folder NOT the 8.1.0xxx? We have had some strange problems occuring and it appears that when I would debug the application using CVI, I would get some fatal run-time errors  (sorry for not being more specific) that would occur in different locations. I then noticed that there was the cvirt.dll and cvirte.dll files (v7.1.1) in my current project directory but not the cvirte folder which contains the bin and fonts folder. Once I put the correct cvirte folder into my project directory the strange runt-time errors went away. Now this little exercise would suggest that when I debug an executable in the CVI environment it is still looking for runtime engine files in the application directory. If it doesn't find them there does it go to the system32 directory?

If this is indeed the case then when we debug our executables CVI is using a different runtime engine than the one that it puts into the distribution kit. I would like to be using the same run-time engine in both my CVI environment and distribution kits.

-Ryan

[majo0008]

Some additional information...When debugging the executable through Labwindows 7.1.1, I call GetCVIVersion() and it returns 811 suggesting it is getting its runtime engine from the system32 directory. Is this true?If I put the 7.1.1 runtime engine in the same folder as the debug executable and then run the debug through Labwindows, GetCVIVersion() now returns 711.

Two Questions:

1) When I am running Labwindows environment, what runtime engine is used and where does it get it?

2) Do I need to always put the correct run-time engine files in my project directory, so that when I debug using labwindows I can be sure I know the run-time engine version? This will also allow me to control which run-time engine is loaded during debugging so I can match the run-time engine in the distribution kit.

-Ryan

[menchar]

I think the CVI runtime engine, as a dll, behaves like any other dll with regard to search sequence.

I believe the search sequence is the same as the Win32 SDK LoadLibrary function:

1. The directory from which the application loaded.
2. The current directory.
3. Windows 95/98: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.

   Windows NT/ 2000: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32.

4. Windows NT/ 2000: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable.

Additionally, you can use the DLL redirection mechanism to force an application to use a specific DLL even if the search sequence has previously registered a different one.  You create a file named   <application executable name>.exe.local   in the application directory, and the OS will always use a DLL from that application directory, even if one of the same name is already registered and known to the system.

This is from the Win32 SDK:

Dynamic-Link Library Redirection

[This is preliminary documentation and subject to change.]

Problems can occur when an application loads a version of a DLL other than the one with which it shipped. Starting with Windows 2000, you can ensure that your application uses the correct version of a DLL by creating a redirection file. The contents of a redirection file are ignored, but its presence forces all DLLs in the application's directory to be loaded from that directory.

The redirection file must be named as follows:

appname.local

For example, if the application's name is editor.exe, the redirection file is named editor.exe.local. You must install editor.exe.local in the same directory that contains editor.exe. You must also install the DLLs in the same directory.

The LoadLibrary and LoadLibraryEx functions change their search sequence if a redirection file is present. If a path is specified and there is a redirection file for the application, these functions search for the DLL in the application's directory. If the DLL exists in the application's directory, these functions ignore the specified path and load the DLL from the application's directory. If the module is not in the application's directory, these functions load the DLL from the specified directory.

For example, an application c:\myapp\myapp.exe calls LoadLibrary using the following path:

c:\program files\common files\system\mydll.dll. 

If c:\myapp\myapp.exe.local and c:\myapp\mydll.dll exist, LoadLibrary will load c:\myapp\mydll.dll. Otherwise, LoadLibraryc:\program files\common files\system\mydll.dll. will load

Note  It is good practice to install your application's DLLs in the same directory that contains the application, even if you are not using redirection. It ensures that installing your application will not overwrite other copies of the DLL and cause other applications to fail. In addition, other applications will not overwrite your copy of the DLL and cause your application to fail.

This question comes up a lot, I'm sure someone from NI can nail this down for you if this doesn't help.  From everything you're saying, it looks to me as if a CVI application looks for the RTE dll the same way any apllication looks for a dll.  The RTE will stick with the latest version of the RTE that's ever been installed, even if you go back and re-install an old version of CVI or a distribution using an older RTE.  We've had to manually rip out newer RTE's to get the older one to reinstall (using the add/remove programs wizard).  This can really fool people not looking for this behavior.


Menchar

[majo0008]

Thanks for the reply. I started to try and remove my 8.1 runtime by going to the Add or Remove.... in the control panel but when I started to uninstall it won't let me uninstall the run-time without also uninstalling Labwindows/CVI. I manually went into the system32 and deleted the 8.1 runtime files and replaced them with the 7.1.1 runtime files but the system still thinks there is 8.1 runtime on my computer. I then went and repaired the installation of the 8.1 runtime files to hopefully avoid any confusion for myself sometime down the road.

So....I will now always include the run-time engine files in my project directory to ensure that I am using the same version on both my development system and in the distribution kit.

Thanks,

Ryan

[menchar]

You can remove just the runtime itself.  Add/remove looks like it's going to remove everything, but when you click remove it should give you a pick list of whcih NI component you want to remove, and every RTE that's been installed should show up separately from any other installed NI software.  Multiple CVI RTE's can be simultaneously installed I believe.

If I'm not mistaken, if the system has registered the 8.1 RTE (i.e. some application caused the system to find and load 8.1 RTE since bootup) and your 7.1 app runs, it will normally use the 8.1 RTE, even if the 7.1 RTE dll is in the application directory.  I think this is why Windows has the dll redirection capability, to force the use of 7.1 RTE in this scenario.

Menchar

Message Edited by menchar on 06-29-2007 10:17 AM

Message Edited by menchar on 06-29-2007 10:18 AM

[majo0008]

So even though GetCVIVersion() returns 711 (which is the runtime version in my application directory), it may actually be running 8.1 runtime engine? 

-Ryan

[menchar]

No.  The GetCVIVersion should report the version being used by the calling app.

But if you were to reboot, then run a CVI application that uses the 8.1 RTE, and the 8.1 RTE is on the system and the application finds it so that the system registers the 8.1 RTE as being the CVI RTE, and then you run your 7.1 app, I think that GetCVIVersion() will report that you're in fact using the 8.1 RTE.

Then again, I could be all wrong about this

Menchar.

[majo0008]

I'll try to test this and let you know what I find. We have been burned by the run-time engines getting out-of-sync before so controlling them is important for us. I will try the .local trick as well.

-Ryan

[menchar]

It will be interesting to see what happens.  I hate to send you off on a goosechase if somebody knows what really occurs in this scenario.

I believe that this is a manifestation of "DLL hell".  dll redirection is one of the Windows mechanism used to overcome this.

I don't know how a CVI app tries to load the RTE dll.  But the distribution kit mechanism provides the ability to drop the RTE into the application folder as well as system32.  There's a checkbox you can use.  This would only make sense if the app will look in the app folder first.

Normally, running a newer RTE with an older app isn't a problem, and that's why all of this behavior is transparent to most users.  We didn't realize we were really running 8.1 RTE with our 7.1 application until we saw a problem with serial i/o (serial library part of the RTE).

And your issue may not be with the CVI RTE dll itself, so much as some of the other, ancillary stuff like fonts, etc.  There are other dll's CVI uses other than the RTE itself.

We've had nightmare scenarios with this issue, using a distribution kit in every case will help, especially if there are dll dependencies other than the RTE that could get screwed up.  We fooled around for weeks on an install once (20 target systems!) - the problem was that the goobers that created the app hadn't used a dist kit and they missed a dll for WordReport.  Worked on any system that had CVI installed (CVI famework had access to the dll) but not on a target that didn't.  I had repeatedly told them to use a distribution kit but they laughed at me   They thought we should install a $2400 tool (CVI) on all 20 target systems

Menchar

Message Edited by menchar on 06-29-2007 11:01 AM

[majo0008]

We ran into some issues when we migrated from Labwindows v6 to 7.1. We now always use distribution kits AND put the run-time engine in the application directory. The redirection method is a nice idea so I will look into using it. Hopefully someone from NI will chime in and give insight on this.  It is very easy for some other installer to get in and install a new run-time engine into the system32 directory without us knowing it. I don't like this but hopefully we can learn to live with it and not rely on the system32 directory for files.

Thanks,

Ryan