HELP! Problem with EXE

[jchiang]

I am compiling an application that I want to distribute to computers without the Laview 7.1 Runtime engine installed so I am bundling the relevant files with my application. All is fine so far.

Problem is that my application uses the Inv Norma Distribution.vi which require dthe lvanlys.dll. So far so good. I put that in the folder with the compiled exe. I still have a problem though. It looks like this vi will only work if the lvanlys.dll is in the C:\Program Files\National Instruments\LabVIEW 7.1\resource folder.

If I remove the lvanlys.dll file from my application directory then I get prompted to find lvanlys.dll when i run the executable. I get an error that obviously suggests it cannot find this dll. When I put the dll there I get another error that says:

An error occured loading VI "Inv Normal Distrbution.vi" LabVIEW load error code 21: An external subroutine required for exection could not be found.

So at this point I have an issue if the dll is not there and even if the dll is there I have another error...

ANYONE GOT AN IDEA??

Thanks,

Jim

[m3nth]

Try copying all of the files into your application directory that would normally be installed with the run-time engine and see if that fixes it. If everything is there it shouldn't be complaining.

[jchiang]

Try copying all of the files into your application directory that would normally be installed with the run-time engine and see if that fixes it.  If everything is there it shouldn't be complaining.

5448[/snapback]

I did try that, and just tried it again. No luck.

Anymore ideas?

[kennoncotton]

Jim,

With LabVIEW 7.1, the lvanlys.dll is not 'self contained' as it was previously. It has dependencies on other DLLs (Math Kernel Libraries) that are installed specificially for the CPU type being used (P3, P4, etc). So you really need to install the LabVIEW Run-Time Engine to not only get the other DLLs but to get the right one.

Kennon

[Barrie]

Jim,

With LabVIEW 7.1, the lvanlys.dll is not 'self contained' as it was previously.  It has dependencies on other DLLs (Math Kernel Libraries) that are installed specificially for the CPU type being used (P3, P4, etc).  So you really need to install the LabVIEW Run-Time Engine to not only get the other DLLs but to get the right one.

Kennon

5460[/snapback]

Hmmm...

Unless I'm missing something, that would imply that the RTE and/or the .exe must need some machine specific information about what sort of machine you want to deploy the app to, during the build. If you wrap up the .exe and RTE together, how does the appbuilder know what the destination machine is?

Further, if one makes a single built app for distribution to a number of different machines, that would imply that some of the installs will not work, or not work as well as they could.

Can anyone clarify this further?

Regards,

Barrie

[kennoncotton]

Hmmm...

Unless I'm missing something, that would imply that the RTE and/or the .exe must need some machine specific information about what sort of machine you want to deploy the app to, during the build. If you wrap up the .exe and RTE together, how does the appbuilder know what the destination machine is?

Further, if one makes a single built app for distribution to a number of different machines, that would imply that some of the installs will not work, or not work as well as they could.

Can anyone clarify this further?

Regards,

Barrie

5461[/snapback]

Actually, machine specific information does not need to be known at build time of the exe or of the installer. The Analysis VIs contain call library nodes that call lvanlys.dll, this DLL determines CPU type and loads the appropriate Math Kernel Library and calls it at run-time. So you could end up with a call chain of Mean.vi->lvanlys.dll->mkl_p3.dll or Mean.vi->lvanlys.dll->mkl_p4.dll at run-time. Since the CPU specific code is in a DLL it doesn't get compiled at build time and also because it is called indirectly it doesn't have to be copied around at build time, we assume the installer takes care of getting it on the system.

I thought that our installer was smart enough to determine the CPU type at install time and install just the MKL DLL needed for the machine it is being installed on, but after looking at it some more, it looks like it is installing all of them all the time. Either way you shouldn't end up with exe/installer that you can use on one machine but not another, because the machine specific code is not directly called by the VI and the installer puts what you need on the target machine. Now if you are just trying to copy the EXE and the files in the RTE over to another machine, you could/would miss these secondary DLLs and might not copy the right one. So it is important to run the installer for the RTE.

Kennon

[m3nth]

Now if you are just trying to copy the EXE and the files in the RTE over to another machine, you could/would miss these secondary DLLs and might not copy the right one.  So it is important to run the installer for the RTE.

5476[/snapback]

I haven't had time to look at this but if they're just files that you "could/would miss" then that means you can go find them and copy them.

There's probably a way to find the external dependencies in the dll code itself but that seems somewhat complicated.

[kennoncotton]

that means you can go find them and copy them.

There's probably a way to find the external dependencies in the dll code itself but that seems somewhat complicated.

5477[/snapback]

Yep, you can always reverse engineer the installer it is mostly copying files and putting in registry entries or instead you could just run it

[m3nth]

Yep, you can always reverse engineer the installer it is mostly copying files and putting in registry entries or instead you could just run it

5484[/snapback]

By the way Kennon, welcome to the forums. I'm not sure that this has been discussed here, but part of the problem with running the RTE is exactly what you mentioned--that it makes registry entries, installs stuff, doesn't clean up after itself automatically, and usually requires administrator priviledges (for making registry entries, which causes it to fail if you don't have admin privs). So a lot of times it's desirable to find the files you need and copy them in an archive for easy deployment. To date, I have not needed to 'reverse engineer' the run-time engine installer since it dumps all the files in one convenient location... at least all the files that my programs use. I don't know about this whole sub-linkage lvanlys.dll bit--I've never had that issue come up--but it is a lot more convenient for me to not have to run the installer on every PC I use. This issue becomes especially important also when creating portable apps that run off of a USB drive. How portable is an app if you have to run an installer every time you use it? On top of the fact that the installer will likely fail without admin privs. So there are definite advantages to finding the files you need and being able to distribute them in one bundle.

[kennoncotton]

By the way Kennon, welcome to the forums.

5485[/snapback]

Thanks. I've been following the forums for a while, I just haven't got around to posting. Which reminds me, I need to see about getting a Texas flag under my name to reflect my true country of origin

I'm not sure that this has been discussed here, but part of the problem with running the RTE is exactly what you mentioned--that it makes registry entries, installs stuff, doesn't clean up after itself automatically, and usually requires administrator priviledges (for making registry entries, which causes it to fail if you don't have admin privs).  So a lot of times it's desirable to find the files you need and copy them in an archive for easy deployment.  To date, I have not needed to 'reverse engineer' the run-time engine installer since it dumps all the files in one convenient location... at least all the files that my programs use.  I don't know about this whole sub-linkage lvanlys.dll bit--I've never had that issue come up--but it is a lot more convenient for me to not have to run the installer on every PC I use.  This issue becomes especially important also when creating portable apps that run off of a USB drive.  How portable is an app if you have to run an installer every time you use it? On top of the fact that the installer will likely fail without admin privs.  So there are definite advantages to finding the files you need and being able to distribute them in one bundle.

5485[/snapback]

If you have a list of things that aren't cleaned up by the RTE when it uninstalls let me know, to my knowledge it should remove everything, if it doesn't then we need to get that fixed.

I understand the convenience of not installing the RTE, in fact I showed how to create a LabVIEW based autorun for a CD at NI Week 2002, so you could have a LabVIEW built EXE launch when the CD was inserted without having to first install the RTE. (BTW I'll be doing a similar presentation again this year, but I'll also be showing what App Builder might look like in the future.)

Even though it is convenient and not too hard to do, as LabVIEW and the RTE get more complicated it will be harder to keep this up. This will work for simple applications where all you need is in the RTE folder, but if you are using DataSocket, 3D Graphs, Storage VIs or other LabVIEW features where you have files in various locations, have to register the DLLs, need certain files for certain OS versions, etc., an installer is the way to go.

Kennon

[m3nth]

Do you have a link to your presentation anywhere online? That would be helpful.

By not cleaning up after itself automatically I meant that the RTE is going to leave a copy of itself everywhere you install it--as compared to a portable USB-drive type app where the files stay with the application and when you're done using them and unplug, the files don't stay installed.

I understand that certain DLL's 'need' registered and become specific to the platform your using, as do the various sub-units of functionality that you mentioned which can be optionally installed or not, but I still (from my perspective), see a need for the end-user of LabVIEW--the programmer--to be able to cull the necessary files if needed and create an application that can be portable.

[kennoncotton]

Do you have a link to your presentation anywhere online?

[m3nth]

Thanks Kennon.

I'm going to go ahead and post the powerpoint here so it will stick around a little longer.

Download File:post-360-1123162043.ppt

[tetrarch]

Dependency Walker might be useful here. It'll help you find most, if not all, the DLLs required.

You may also need to run

regsvr.exe XXX.dll

for each one, depending on whether it's COM or just a library.

[m3nth]

Dependency Walker might be useful here.

5543[/snapback]

Cool..... that looks like a nice utility I will be downloading shortly :thumbup:

[Rolf Kalbermatter]

Cool..... that looks like a nice utility I will be downloading shortly :thumbup:

5544[/snapback]

It probably won't help in this situation alone. I believe that the location and version of the Math Kernal Library is registered in the registry too at install time and this is used on load time of the lvanlys.dll to link to the appropriate DLL. This is the reason you get the different error message as the DLL can't find the registry entries or the DLLs and therfore has to abort as it really is only a wrapper around the Math Kernel libraries.

Of course you can try to figure this all out but chances are that the Math Kernel Libary or something else will change again in the next LabVIEW version and then you can either decide to stay with your current LabVIEW version, try to figure out the new dependencies, or go with the flow and use the Installer anyhow. Expect this to be a never ending battle if you don't want to go with the Runtime Sytem Installer.

Rolf Kalbermatter