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.

[JackDunaway]

You think those executables do not require a runtime engine, but they probably are using shared libraries that already exist in your OS installation. If you were to delete the right DLL in your system folder, you could effectively disable those programs that "don't require a runtime installation". It just so happens that your OS doesn't ship with LabVIEW RTE components (obviously), so it really sticks out when LV executables have to include a RTE that's 100's of MB.

Although it would be unlikely to fully eliminate the LabVIEW RTE, fundamentally I feel the same pain you do. The LabVIEW RTE is too big. Check out this idea: Segment the LabVIEW Run Time Engine (RTE) to ONLY Necessary Components as a means of reducing distribution size and time to install.

Anyway, Kudos, I wish we could get get rid of the RTE altogether as well. 🙂

[smercurio_fc]

There's no probably about it. They are definitely using libraries that are already installed on the system. Until the way operating systems change this will never happen. It's the same way with Java, Perl, .NET, Python, etc. etc.

[ErnieH]

Thanks for the comments. Yes, I am sure it uses shared libraries. The point is the end user usually does not have to install anything to use the program I would send. Even if I had to use a small installer or downloaded some dll’s, that would be ok.  It just shouldn’t change every year for this reduced set. Then, it would then not matter what version of LabVIEW I developed it on. It would simply work when it arrives.

[smercurio_fc]

It would only change "every year" if you recompile the code in a new version of LabVIEW. If you compiled the application with, say, LabVIEW 7, then you would need the LabVIEW 7 Run-Time. Even if today LabVIEW 2009 is out.

It's the same exact way with Java, .NET, Python, etc., etc. 

[Dennis_Knutson]

I would be strongly opposed to going back to the old days when the exe included the runtime.

[ErnieH]

I think you are missing my point. I want to be able compile so that I do not need the LabVIEW runtime engine. Just a reduced palette of objects that I can build into an executable using the standard libraries included in the OS already. Or, maybe a LabVIEW version independent compile that does not change with every version of LabVIEW. Maybe using a runtime engine that is small with base functionality that does not change very often. Just would like to be able to distribute executables quickly to people for simple applications if I need to without worrying about the runtimes.

[JackDunaway]

Dennis, it all depends on your group's distribution schedule, how they are shipped, how often they are updated... some want a lightweight installer, some want a full-featured installer. Go back to the idea of segmenting the run-time engine as the developer sees fit linked above, and I think most developers would end up happy.

[Dennis_Knutson]

To totally eliminate a LabVIEW runtime, it would seem to me that would force you to use nothing but Microsoft controls (i.e. ActiveX, .NET) and use the Microsoft windowing scheme, etc.

A reduced runtime might be possible but it could also lead to mass confusion when an end user has no idea which runtime should be downloaded. You are aware that there are two flavors of runtime right now, aren't you?

[JackDunaway]

Two flavors include standard (160MB) and minimum (36MB) RTE. And when I vote for "eliminate" the RTE, I mean statically link the necessary components into the executable, instead of dynamically linking to a separately installed RTE. (This is a long shot... I still think a better solution would be to segment the RTE). And again, it boils down to your distribution style. Is your software running on customer hardware or a computer you supplied? Who is authorized to install your software updates - the customer or one of your own service reps? What's more valuable, space or time? How many of your apps will the customer ever run... one, or a wide variety?

I agree that if a customer is required to download and install a RTE, by all means, give him one option, and no chance to screw up! But if the RTE is going to be bundled in a software distribution, allow the developer to selectively include only what's necessary.

[CrystalTech]

As I understand it, you just don't want the user to mess with installing the Run Time Engine.  So if NI could somehow incorporate it in the executables you make, it could place the proper Run Time components in the proper location if they don't already exist.  I like it.  Doable?  I don't know.  But I like it!!! 🙂