LabVIEW
LabVIEW 2024 build exe for older version
Solved!
@Worle wrote:
I am just having a look at LabVIEW 2024 and its ability to save files for a previous version.
Does anyone know if it also allows you compile an exe to run on a previous version of the runtime?
By the looks of what is listed in the additional installers it can't. (I have got a project which is set to be save in 2023, but the installer is listing the 2024 runtime).
This suggests that in order to compile a project you will still need the target version of LabVIEW installed.
Your question is not clear. If you compile the code to an exe, shared library, or packed library, it is in whatever version your LabVIEW version was that you used to build that binary file.
If you set the "keep source in previous version" to a previous version, the VI source code will be kept in that version and you can transfer the VIs to a different computer and open them in that version or a newer one! (With the exception of some bugs in some corner cases that still need to be ironed out. Make sure to use LabVIEW 2024Q3Patch2, it fixes several bugs about "keep source in previous version").
Actually you don’t need to suspect conspiracies or ulterior motives. There is a very technical reason that this would be pretty much impossible to implement!
While it is quite a lot of work but doable to try to keep APIs backwards compatible so that an older application will see the same interface when loading with a newer runtime, the opposite is at least a magnitude more difficult. The application would need to include an ever increasing mapper component that tries to map newer API calls to the older ones in the old runtime to be able to run on the old runtime. And that mapper component soon will get similar in size as the old runtime itself as it needs to implement everything the old runtime doesn’t know about. And that all needs to be done conditionally for every supported backwards runtime.
Adding a new feature to LabVIEW would suddenly require an even bigger effort and one that is difficult to oversee, exponentially growing with every older version you want to support and basically end up requiring a runtime_mapping runtime installer.
Worse even, most new features would be impossible to implement! Yes you read that right! They often need access to internal facilities in a runtime that are not exported in any way and shouldn’t be exported ever. The mapper component would be unable to seamlessly implement that feature with the exported functionality in older runtimes. Result: sorry guys this feature can’t be supported with the “compatible to older runtime” requirement. You either abandon that requirement or we can’t add that feature. So long and thanks for all the fish!
Net effect: A lot more effort, much more potential for bugs and difficult to test for compatibility issues, less new features implemented and still an additional runtime like component to install!
Sounds to me like “All pain and no gain” except the bragging right to have done something silly and to have created another money dumping hole.
I rather would use that money to send the developers for a few days a year to a resort to have fun and return home to create new exciting features, instead of this! 🎉🍹
