LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why Labview runtime is not backward compatible ?

Solved!
Go to solution

Hello,

I attemped to run an Labview program compiled by a 32bit 2013 Labview license on a 64 bit Windows PC with 64 bit 2014 Runtime engine. Unfortunately it failed out right and required me to install a 32 bit 2013 Runtine engine.

 

I thought if a PC is 64 bit then I need 64 bit runtime engine. Is this not correct ? And is it true that a machine running executables must have the exact same runtime engine version as the ones that they were compiled from ?

A minor thought, is it likely that a labview program might run "differently" on different engine versions ? say, flatten to string for examples, ...

0 Kudos
Message 1 of 5
(4,326 Views)

@zigbee1 wrote:

Hello,

I attemped to run an Labview program compiled by a 32bit 2013 Labview license on a 64 bit Windows PC with 64 bit 2014 Runtime engine. Unfortunately it failed out right and required me to install a 32 bit 2013 Runtine engine.

 

I thought if a PC is 64 bit then I need 64 bit runtime engine. Is this not correct ? And is it true that a machine running executables must have the exact same runtime engine version as the ones that they were compiled from ?

A minor thought, is it likely that a labview program might run "differently" on different engine versions ? say, flatten to string for examples, ...


No, it's not true.  What is true is that you have to install whatever runtime engine it tells you to install.  😉

 

If your application is 32-bit, it requires 32-bit versions of whatever it needs to run.  it doesn't matter that your computer is 64-bit.  This is not limited to LabVIEW, of course.

 

And no, runtimes are almost never backwards compatible.  Just look at how many versions of .NET you need to install these days.

 

[edit] sorry, that came out way harsher than i intended.  [/edit]

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 5
(4,306 Views)

wow, that's odd. I didn't know that.

0 Kudos
Message 3 of 5
(4,299 Views)
Solution
Accepted by topic author zigbee1

You need the run-time engine version that matches the version of the development system used to build the application. This includes bitness (32-/64-bit). Since you can only run a LabVIEW application with one run-time engine version - the one that was used for development - there's no reason to ask if it would run differently on different run-time engines, since that can't happen. That said, NI tries not to change how functions work between versions, and when such changes are unavoidable they are usually documented and there's often an option to use the old format (some functions have right-click options to be compatible with older versions).

 

Windows has a special feature, known as Windows on Windows (WoW), that allows 32-bit applications to run on a 64-bit operating system. Without this, you would only be able to run 64-bit applications. WoW does not, however, allow a 32-bit application to load 64-bit libraries (with the exception of the system libraries that make WoW work). The run-time engine is mostly a set of support libraries. Your 32-bit application can't load the 64-bit run-time engine libraries (they don't agree on the size of a pointer, which makes it impossible to pass data reliably), so you need the 32-bit run-time engine. Likewise, if you built your application using the 64-bit development environment, you would not be able to run it in the 32-bit run-time engine.

0 Kudos
Message 4 of 5
(4,296 Views)

thank you, its very well explained  🙂

0 Kudos
Message 5 of 5
(4,288 Views)