Backwards compatibility of the run time environment (RTE)?

[dthor]

Hey All,

Before I go post this on the Idea Exchange, I just wanted to make sure that it it in fact true that the 2012 RTE is not backwards compatible with the 2010 RTE (or any other previous RTEs for that matter).

Thanks,

[Matthew_Kelton · Accepted solution]

It's true.  You need the corresponding RTE for the version of LabVIEW in which you compiled your application.  I would search the Idea Exchange, because I think I have seen that idea before and it has been shot down by NI.

[dthor]

Ok good, I'm not going crazy then.

I checked the Idea Exchange and didn't see anything for this, so I posted it here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Backwards-compatibility-of-the-run-time-environment-RT...

I'd imagine it's pretty hard to accomplish, but there's no harm in trying!

[Dennis_Knutson]

I believe that in order to have backwards compatibility, the older VI would need to be recompiled. In order to be recompiled, the run time would need to include the compiler and the exe would have to include the block diagram.

[altenbach]

Well, they could offer a "universal run time engine" that includes all previous run time engines in one package, all in one universal installer. Of course it would be quite a bit bigger. If would update itself if new versions are added as part of the update notifications.

A better option would be that built executables would offer to automatically download and install their required run time engine if it is not found (similar to java, flash, etc.), so vote here if you haven't already. :D)

[dthor]

---

@altenbach wrote:

so vote here if you haven't already 

---

Oh don't worry, I voted on that a long time ago...

[rolfk]

No system I know allows such compatibility between different runtime version. Not because nobody has tried, but because it is essentially impossible if you do not want to either duplicate most things for every version you want to support or force a feature freeze which would make the release of new versions pretty useless anyways.

It would mean that whoever installs 2012 RTE also gets in fact the entire 2011, 2010, 2009 and so on RTE installed, minus a few shared components.

When LabVIEW loads a VI from a previous version, there are many so called mutations that happen in the background. Nodes that have been changed are automatically rewired, the entire machine code is recompiled from the diagram source to make use of the newest and greatest compiler optimizations in the new LabVIEW version, etc, etc. Unless an RTE installer would simply go the easy route of including all previous RTEs in parallel (and create a well over one GB runtime installer) it would mean the RTE would have to include almost everything the development environment does too, including mutation code for previous versions, the entire compiler system, and several other things.

Much of extra engeneering effort would be needed for that and it would still not be always a seemless experience.

[GJMABerends]

From my own experience I can say this much,

Extra code is needed to keep something backwards compatible. More code implies (does not have to be) more complex software. More complex software makes it harder to maintain let alone to improve. Thus it is a balance: does NI wants to improve LabVIEW? or, keep LabVIEW fully backwards compatible? 

Of course we want both, and you can say that code isn't well written if you can't do both. But, design rules and recommended patterns do change (let allone the primals). What may be the recomended style now, can be bad style in the near future. And what about the removal of bugs or the changes in the OS that influences LabVIEW backwards compatibility?

It is a design choise of NI based on a loth of different requirements and a loth of different stakeholders. And from my view point it makes sense. But that doesn't mean I like it. 🙂 So no you can not expect full backwards compatibility to earlier versions. Just download the right RTE for now, maybe in the future it will change.