LabVIEW
Why labview 2019 cant open VIs written in 2020?
(not a loaded question, I'm just curious)
Hello all,
a question I'd always like to get answered is why older versions of labview cant open VIs written in newer versions. Take a look at a super basic example:
What does it really matter if this VI was written in LV2010 or if its written in 2020? As it uses a primitive function which supposed to work the same way. I can imagine that from time to time NI reworks the how files are stored on the hard drive, but does it really been reworked for all the versions? If you have a python script written in python 3.x but you only have python 2.7 installed then you can still open it and even if you can't execute it (although many times you can) you certainly can read the code to get an idea whats going on. At some degree I would understand if VIs written in 2020 cant necessarily be executed in an earlier versions, but not even being able to open VIs written in newer versions is a huge limitation.
Is there any practical reason behind this or is it simply a business decision from NI?
Thx!
@1984 wrote:
What does it really matter if this VI was written in LV2010 or if its written in 2020? As it uses a primitive function which supposed to work the same way. I can imagine that from time to time NI reworks the how files are stored on the hard drive, but does it really been reworked for all the versions? If you have a python script written in python 3.x but you only have python 2.7 installed then you can still open it and even if you can't execute it (although many times you can) you certainly can read the code to get an idea what's going on. At some degree I would understand if VIs written in 2020 cant necessarily be executed in an earlier versions, but not even being able to open VIs written in newer versions is a huge limitation.
And how would LabVIEW 2019 know if LabVIEW 2020 changed the VI format? Any new source features (ie new data types, primitives, structures, tunnels, etc) pretty much requires a format change. Unfortunately, this is just the main problem with binary files. Python, and most other programming languages, do not have this problem since the source is just simple text files.
NXG attempted to solve this issue by using an XML format for the VIs. Unfortunately, that did not appear to be working and the problem was way more complex than it seemed on the surface. I remember talking with Stephen Loftus-Mercer about this, but I don't remember the details.
Coming back around, there is a possibility that if you require separate from compiled and no new source features are created, then (I am making up versions here) LabVIEW 2024 could save the VI as if it was LabVIEW 2023 without the Save For Previous and then we are good for a single version. I think this would be more of an exception than a rule as you would be forced to push out specific types of features specifically for a version epoch.
@AeroSoul wrote:
Wouldn't it be possible (perhaps even better) if a "clone" was opened instead of VI, and all the functions etc. would get replaced with functions from the version of LabVIEW with which you opened the VI?
Any unavailable functions and subVIs would get replaced with the ? box.
This way you avoid the compiled code shenenigans and any compatibility issues, if functions changed.
I mean literally anything would be better than the popup box it gives now (even just a damn picture of a code would be better than nothing at all).
They already do this for executables and the runtime - and it's already led to unexpected behavior.
Another question to ask: How many future features are you willing to sacrifice for this?
Making the binary format future proof by hammering it in stone and not allowing any changes to the binary structure for new features is very hard, costs a lot of effort and is still not guaranteed to work. It would definitely require a COMP:LETE redesign of how VIs are currently saved. Lots and lots of work for a fairly limited effect.
It's already quite a bit of work to guarantee backwards compatibility,
Consider this: You have a LabVIEW VI and save some configuration to a file. You can do this in many ways, for instance simply saving the configuration structure into a binary file. Now you update your software and add an extra element to that cluster. Bam all your old configuration files are worthless. This is just reading old existing files! Doing the opposite by trying to make the format future proof requires even more work! LabVIEW VIs are MUCH more complex than a simple cluster flattened to a byte stream. The work for making it read old files correctly is already immense. To make sure it works, requires tons and tons of regression tests before every single new release, and yes that applies even for minor bug fix releases. Testing for an unknown yet future format compatibility is totally impossible until someone develops a time machine. It would also at least exponentially increase the number of regression tests that need to be run, with absolutely no guarantee that a new version won't somehow require a format change for a new feature that the old routines simply can't handle!
