Build executibles that don't require a runtime engine

[ErnieH]

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.

[altenbach]

The current form of the executable+runtime is certainly good for most scenarios and should be the default. 

This idea goes along the lines of creating a self-sufficient LabVIEW executable that can run directly from CD or memory stick on any public computer and without the need for administrator privileges.

As long as if it fits on a DVD, size does not really matter. 🙂

Basically, the project needs an additional "built specification": standalone executable. It would include the basic executable and all extra stuff it needs in a defined hierarchy right next to it. It could even have an option to create an ISO file or burn a CD/DVD, including an autorun.inf entry (and icon) to start the program when the CD is inserted. This would be ideal for demos.

[JÞB]

KUDOS!  but only for spawning thought.  You brought up a great discussion point and have sparked a series of comments comparing the LVRTE to other platforms.  Taken a step farther...

  I OFTEN get messages that a(n) JAVA, ADOBE, Windows, ORCAD, YADA-YADA ad-nausem... update is available.  LabVIEW development environments do not do this (or I disable them) but provide a user tool to look for updates on the NI site.  LVRTE has no equivalent of an update feature whatsoever.

So, Which paradigm is prefered? Automatic or selected updates?  Would either paradigm for updates break the LV backward (non)compatability model for the RTE?  Would Automatic updates for the RTE enhance the bug fix (patch) deployment model for LV?

Again, good discussion.

[JackDunaway]

altenbach, Build Spec: Standalone Executable. Bingo, thanks for verbalizing the essence of what I could not spit out in three posts. That's the type of executable that I feel would best suit our group's distribution schedule.

[Intaris]

This approach (while I would also welcome it depending on the deployment method) probably won't work as soon as VISA is being used.....

But for those applications where no hardware drivers are required, I would like to see this option.

[RichardJennings]

I would very much like a smaller exe and/or an exe that could run from a CD/DVD.

[PJM_Labview]

I think we could consider an alternative idea where if you gave somebody an executable that is missing a specific runtime engine it could prompt the user with a dialog message around these line:

This "your application name" requires additional components that are not installed on your system. Do you want to download and install them now"?

While this would not necessary be fool proof, this would definitively improve the user (and developer) experience.

[Mads]

The old way of having everything included in the executable was better in so many ways. I could send people a full installation that would be just 5 MBs when compressed...now the same application takes 120-140 MBs.

Hard disk space is not much of an issue anymore, but e-mail and file download limitations are...and as the old way demonstated - it's possible to avoid it.

We always have include the RTE because the customers seldom have it already (why would they). The argument that you only need one RTE and should not include it in every app does not work either as you would need a lot of the old all-in-one applications to get to the size of one of today's RTEs.

As longs as the language depends on an RTE that is not in regular distribution it should always be an option to build a stand-alone application. Yes, it would be better if the installer would detect the need for and automatically download the necessary components from the Internet, preferably more segmented than today to minimize the download time, but it's not the ideal solution.

[smercurio_fc]

It seems this idea has morphed into a "Make the Run-Time Engine Smaller" notion rather than a "Make it so a LabVIEW app doesn't need the Run-Time Engine in the first place", which as already indicated, is not possible. Given that, it's not clear which one is getting the Kudos.

[Mads]

Stand-alone exectuables were possible before (LV 7 and earlier if I remember correctly?), and was a much better solution when it came to distrubution. If a customer needed one of our apps we could send him everything in an e-mail that was 4-5MBs....now we have to send them 120-140 MBs, and there is no advantages for the customer. Unless the customer has more than 4 of our applications the total disk size used would also be less with the old all-in-one executable.

I think that as long as it's not common to have the RTE it is better to not have an RTE solution...Java, .Net etc. is so common that you can expect users to have the RTE, or to find it easy and natural to download it. That is not the case for the LabVIEW RTE.

A solution that automatically downloads it if required, and that keeps the download to an absolute minimum (more segmented run-time..there is so many things today that gets installed even with just the basic module that is not really required by the apps we build), would be better than what we have today, but in our case most of the installations are one oil-rigs and we can not rely on them being able to download very large files.

Message Edited by Mads on 03-02-2010 03:17 AM

[Dennis_Knutson]

It was LabVIEW 5.0 or 5.1 that was the last to have the runtime as part of the exe and as the runtime has gotten larger, an exe would grow as well. As soon as you have a second exe, you see the benefit of a separate runtime.