LabVIEW Idea Exchange

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

Build executibles that don't require a runtime engine

Status: New

I would like to be able to create executables that don’t require the runtime engine in LabVIEW. Perhaps a palette of basic functions that can compiled without the runtime engine and an option in the application builder for that. I routinely get executables from programmers that don’t require a runtime installation. I just put it on my desktop and it runs. It would be nice that if I get a request, I could create, build, and send them an exe in an email without worrying about runtime engine versions, transferring large installer files to them, etc.

37 Comments
AristosQueue (NI)
NI Employee (retired)
CrystalTech: LV used to work this way. So, yes, it is possible. I wasn't around when the change was made, but my understanding is that we stopped maintaining support for that system because it added to the maintenance burden and so few customers used it and the installation of dependency DLLs was becomming standard practice for most of the world's apps.
JackDunaway
Trusted Enthusiast

Dennis, agreed, once you start delivering multiple programs/suites to a customer, they will benefit from having smaller programs/suites and a larger but full-featured and reusable RTE. However, if your deliverable is a single product, you would MUCH rather have the RTE statically built into the executable.

 

What category do most professional LabVIEW developers fall into: multiple products targeted to a customer's machine, or a single program/suite per machine? I wouldn't be surprised if the second population is bigger, which is why Build Spec: Standalone Executable is so enticing. (not to mention I could carry around LabVIEW programs on my USB drive and use them on any computer!)

 

Of course today's entire RTE footprint should not be included into a standalone: it must be segmented to include only dependencies at build time with the developer's prerogative to include more elements for dynamically lauched plugins.

JackDunaway
Trusted Enthusiast
AQ, added to the maintenance burden? It seems it would be a maintenance relief! If the libraries were included in the .exe, upgrading my app on a customer's computer would be a simple as rewriting the old executable. Even when incrementing through LabVIEW releases.
Intaris
Proven Zealot

Jack,

 

I am with you all the way.

 

While I appreciate the usage of a seperate Run-Time for most applications I also can appreciate the applications where a severely reduced Run-time could be of interest.

 

Maybe we need a new execution target "Mini embedded run-time" for a project which then only exposes the functions available in the greatly reduced Run-Time.  I'm pretty sure there's a whole bunch of stuff in the Run-Time which could be cut out for such applications.

 

NOTE: I'm not talking about "standard" applications.

 

Shane

Mads
Active Participant

With LV7 we could just include some support files (lvrt.dll etc.) and create an installer on our own...making the full installation a 5MB download (same code as we today need 120 MBs for). It's the ease of distribution that has disappeared now.

JackDunaway
Trusted Enthusiast

I am hesitant to support a position that goes down the path of "a palette of basic functions that can compiled without the runtime engine" from the original post or "a project which then only exposes the functions available in the greatly reduced Run-Time" from Intaris' post two posts ago.

 

Who's to say I don't want just one function not included in the "base package?" Would the "base package" include 3D graphs, all the advanced math, networking? You can't make everyone happy with the base package, so don't even try!

 

No, there should be no limits on what LabVIEW elements you include in your program. It's just that if you want to include those elements, you must be willing to pay the footprint required for the runtime libraries to support that feature. It's just that we need a way to segment the run-time libraries to include ONLY what is required by the executable, and those libraries need to be a part of the executable, not as a separate engine.

Mads
Active Participant

The arguments for RTE's might seem logical to some...but I think it says a lot that it has now become a niche market to make programs that allow you to avoid them:

 

http://www.vmware.com/products/thinapp/

 

http://www.xenocode.com/

 

If NI made a new product that allowed me to build all in one apps in LV again I would buy it too....but that should not really be necessary now should it? 😉

ErnieH
Active Participant

I did discover an innovative product that allows me to use LabVIEW to create executables without a runtime. I am now able to program, compile, and send a small app to my users that will work without anything else installed. They are extremely happy with it.

Knight of NI

Would you care to provide more details? Are you sure this "innovative product" isn't simply bundling the Run-Time Engine with your installer. Which the NI Installer can do already?

David_Lieberman
Member

I am coming in very late to this but...

 

Using labview 7 I created an application which I distributed on CD which ran right from the CD which did NOT require an installer.  All of the labview runtime stuff was bundled with the exe on the CD. I did this for both Windows and MacOS. Now I am having a devil of a time duplicating this in Labview 11.  You seem to be telling me it can't be done.

 

I cannot stress how important this is. Many people who buy apps that do not use hardware do not want to have stuff permanently installed on their computer.  That is why browser based applications are so popular. If I buy (to take a silly example) Tetris, I want tetris.exe and NOTHING else and when I drag tetris.exe to the trash my computer should look just like it did before I bought it.

 

If somebody can tell me how to do what I once did without enormous difficulty, please let me know.  If it is not possible then I think this is a major defficiency of Labview.