LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
JackDunaway

Segment the LabVIEW Run Time Engine (RTE) to ONLY Necessary Components

Status: New
For distribution, only package necessary libraries in installer packages built with the project. A lightweight UI, server, or client does not need a full 70MB+ installer that bloats out to a few hundred MB's once installed! A colleague has remarked that the total size of our LabVIEW application+RTE EXCEEDS the entire size of the XPe image running on the embedded computer! This becomes an issue when distributing software upgrades to places in the world without high-speed internet connectivity.
15 Comments
fomine
Member

I have gotten several requests to explain how to shrink your RTE installer, so I just explain it here.

 

It's not really a black magic, but rather scrupulous work:

 

I have taken the RTE from its install directory. You can easily do it by installing an RTE onto a "clean" machine.

Copied all the content of the RTE folder and my compiled app to the same directory on a brand-new machine, and started to delete things.

Delete-check if it works-> Undo Delete or delete more Smiley Happy

VISA is a bit more complex, I do not recall how exactly I figured which installers I needed, probably started with bare NIVISAruntime.msi, and gave it what it needed for successful install (NIVISAruntime_mft.cab and NIVISAruntime1.cab)

 

So, now I have VISA RTE installer (3 files, listed above, 3M total) and a bunch of files from LabVIEW RTE, sitting in the same dir as my app:

English directory

Models directory

Files (all dlls):

lvrt

mesa

niCPULib

nierInterface

NIQtCore_2014

NIQtGui

TqManager452_2014

 

tdtable.tdr

 

If you are using math functions (dll calls under wrappers) you will need math lib (it's named something quite obvious to recognize). I rather replaced those with manually written equivalents.

Other dll calls (under NI wrappers) will require other dlls - you can easily check what dll they need, by digging into the wrappers and finding dll calls.

Just add those dlls into your folders, and you will be good to go.

I did not dig into support for more advances functions like classes, connectivity, xcontrols etc, as this was intended only for simple apps for my customers. But the same principle of Delete-check - repeat should apply.

 

No need to install LabVIEW RTE anymore, only need to install NIVISAruntime.msi. The app itself is just copy-paste of the folder with your app + a few files from RTE, or run off a memory stick or such. This is the real beauty of this approach.

 

Good luck, folks!

 

Evgeny

-fomine
_________________________________
You can do greater things with LabVIEW!
smithville
Member

@JackDunaway wrote:
For anyone following along, I have posted an article about how to achieve this (don't hesitate to drop a line if you get stuck!): http://wirebird.co/Minify-RTE

Jack,

The link does not seem to work any more. Do you have another?

 

RnDMonkey
Active Participant

@smithville

From my wanderings around the community, it appears that @JackDunaway is not really in the LabView scene anymore. At least, he hasn't posted on these forums for over 8 months now, and wirebirdlabs appears all but defunct with only an email form on his website. All his old content seems inaccessible. Sadly, it looks like his business didn't work out, or life had other plans that otherwise occupy him now.

____
Ryan R.
R&D
RnDMonkey
Active Participant

On a different note, I very much feel that this is still an excellent idea. The concept of a Build Spec: Standalone Executable is very much enabled by segmenting the LabVIEW Runtime so that only subsets of dependencies can be referenced. If depencies of a built executable could be determined down to the level of individual modules in the runtime library, then statically linked into the executable, then perhaps a truly portable executable could be built. This, I think, would meet all the various requests for "LabVIEW executable without runtime engine", "standalone LabVIEW program without installer", and "runtimeless installer" that have haunted the community for the last 8 years.

____
Ryan R.
R&D
MGiacomet
Member

Yes!!! And this idea is SEVEN years old and things keep getting worse...

 

The installer executable even includes things that'll never be used by the end-users, like such as examples (NI-CAN), C header files, identical folder contents (!) under

"Program Files (x86)\National Instruments\Shared\LabVIEW\2011\LWS"

"Program Files (x86)\National Instruments\Shared\LabVIEW\2012\LWS"

"Program Files (x86)\National Instruments\Shared\LabVIEW\2013\LWS"

"Program Files (x86)\National Instruments\Shared\LabVIEW\2014\LWS"

"Program Files (x86)\National Instruments\Shared\LabVIEW\2015\LWS"

 

Funny (not!) is that the the files under 2012/2013, above, were rebuilt in 2016..., while the ones under 2014 were built in 2013...