Darren's Weekly Nugget 05/10/2010

[Darren]

FYI the fact that this bug broke apps using the backwards compatible runtime engine was the primary motivation for it getting fixed.

[wiebe@CARYA]

---

@Hooovahh wrote:

I'm glad this setting can be turned off, but I can't know what bugs future runtime engines will add.  I like the flexibility of allowing other runtime engines to be used in my application without needing to make a new binary, but it is too much of a risk that something will break.

---

The option should be: "use newer runtime engine if my runtime engine isn't available".

Note that dlls (and ppls?) with this option on don't use the development RTE when developing. So there are 4 combinations of run time engines for (compiled) code vs compiled dependency, causing problems that can be very hard to diagnose.

To make this worse, it only shows when there are more than 1 RTEs to begin with. So this could go unnoticed until delivered, or until a customer installs another application.

[jyoung8711]

---

wiebe@CARYA wrote:

---

@Hooovahh wrote:

I'm glad this setting can be turned off, but I can't know what bugs future runtime engines will add.  I like the flexibility of allowing other runtime engines to be used in my application without needing to make a new binary, but it is too much of a risk that something will break.

---

The option should be: "use newer runtime engine if my runtime engine isn't available".

Note that dlls (and ppls?) with this option on don't use the development RTE when developing. So there are 4 combinations of run time engines for (compiled) code vs compiled dependency, causing problems that can be very hard to diagnose.

To make this worse, it only shows when there are more than 1 RTEs to begin with. So this could go unnoticed until delivered, or until a customer installs another application.

---

I agree wholeheartedly about this.  There was a bug a couple of years ago (I forget what version), where when you dropped a file into a path controller it added a "null" character to the end of the path.  Before this, I didn't realize that LabVIEW always preferentially used the LATEST runtime even if the original was installed, and in this case it took me a while to figure out that's what was going on... So many things just stopped working and it was a nightmare.  It then rippled out to various customers too.  Since then I've started leaving this checkbox unchecked except in a few very specific instances.

One thing I have found is that PPLs will execute in whatever runtime the calling EXE (or dll) is running in (as far as I can tell).  This enables me to leave the checkbox unchecked for most PPLs, and then enforce the runtime used only by recompiling the target EXE.

[wiebe@CARYA]

---

@jyoung8711 wrote:

One thing I have found is that PPLs will execute in whatever runtime the calling EXE (or dll) is running in (as far as I can tell).  This enables me to leave the checkbox unchecked for most PPLs, and then enforce the runtime used only by recompiling the target EXE.

---

But if you have to leave the checkbox unchecked, you need to re-build the ppl for each version of LabVIEW...?

The function is great in theory, but just uncontrollable in practice. With a little TLC it would be unconditionally great. High hopes...

[jyoung8711]

---

wiebe@CARYA wrote:

---

@jyoung8711 wrote:

One thing I have found is that PPLs will execute in whatever runtime the calling EXE (or dll) is running in (as far as I can tell).  This enables me to leave the checkbox unchecked for most PPLs, and then enforce the runtime used only by recompiling the target EXE.

---

But if you have to leave the checkbox unchecked, you need to re-build the ppl for each version of LabVIEW...?

The function is great in theory, but just uncontrollable in practice. With a little TLC it would be unconditionally great. High hopes...

---

Yes, that's true.  

The strategy I've found useful, is to control RTE version explicitly at the EXE level and leave the PPLs checked so that they can run anywhere. 

This means if I want to change LabVIEW runtime versions, I only have to recompile the final EXEs (which are typically small and fast because of the PPLs).  This works well... most of the time....

I ran into some weirdness when I went from 2018--> 2020, and more recently had some issues with 2023 as well with a couple of executables.

[wiebe@CARYA]

---

@jyoung8711 wrote:

---

wiebe@CARYA wrote:

---

@jyoung8711 wrote:

One thing I have found is that PPLs will execute in whatever runtime the calling EXE (or dll) is running in (as far as I can tell).  This enables me to leave the checkbox unchecked for most PPLs, and then enforce the runtime used only by recompiling the target EXE.

---

But if you have to leave the checkbox unchecked, you need to re-build the ppl for each version of LabVIEW...?

The function is great in theory, but just uncontrollable in practice. With a little TLC it would be unconditionally great. High hopes...

---

Yes, that's true.  

The strategy I've found useful, is to control RTE version explicitly at the EXE level and leave the PPLs checked so that they can run anywhere. 

This means if I want to change LabVIEW runtime versions, I only have to recompile the final EXEs (which are typically small and fast because of the PPLs).  This works well... most of the time....

I ran into some weirdness when I went from 2018--> 2020, and more recently had some issues with 2023 as well with a couple of executables.

---

I don't see how that works.

If the option is untagged, I think the PPLs shouldn't run in a newer RTE?

I know for DLLs, they will use the newest RTE if this option is on. If it's off, a newer RTE won't work. The problem is VI server things in the dll fail if the DLL's RTE isn't the source or exe's RTE. So: untagged it won't work in a newer RTE, tagged it won't work in source, but it might work if the exe has this option tagged (it will also use the newest RTE). 

[jyoung8711]

---

wiebe@CARYA wrote:

---

@jyoung8711 wrote:

---

wiebe@CARYA wrote:

---

@jyoung8711 wrote:

One thing I have found is that PPLs will execute in whatever runtime the calling EXE (or dll) is running in (as far as I can tell).  This enables me to leave the checkbox unchecked for most PPLs, and then enforce the runtime used only by recompiling the target EXE.

---

But if you have to leave the checkbox unchecked, you need to re-build the ppl for each version of LabVIEW...?

The function is great in theory, but just uncontrollable in practice. With a little TLC it would be unconditionally great. High hopes...

---

Yes, that's true.  

The strategy I've found useful, is to control RTE version explicitly at the EXE level and leave the PPLs checked so that they can run anywhere. 

This means if I want to change LabVIEW runtime versions, I only have to recompile the final EXEs (which are typically small and fast because of the PPLs).  This works well... most of the time....

I ran into some weirdness when I went from 2018--> 2020, and more recently had some issues with 2023 as well with a couple of executables.

---

I don't see how that works.

If the option is untagged, I think the PPLs shouldn't run in a newer RTE?

I know for DLLs, they will use the newest RTE if this option is on. If it's off, a newer RTE won't work. The problem is VI server things in the dll fail if the DLL's RTE isn't the source or exe's RTE. So: untagged it won't work in a newer RTE, tagged it won't work in source, but it might work if the exe has this option tagged (it will also use the newest RTE). 

---

I think you may have misread my comment (checked vs unchecked), or maybe I'm misunderstanding your use-case description. 

For PPLs my understanding that they will always execute in the calling EXE / DLL runtime which means:

If a PPL is compiled in (say) 2020, and the EXE is compiled in 2023 then:

• If the PPL option is checked, the EXE will run just fine
• If the PPL option is unchecked, the EXE will fail because it can't load from the older runtime, so it will get an error (either "broken" exe if it's loaded on start-up, or an error on the wire if it's loaded dynamically.

I typically leave my PPLs "checked" so they'll run in any LV version, but then "Uncheck" my EXEs so they're locked down, which then dictates the runtime for everything running.

I'm less familiar with DLL functions... I think it invokes it's own RTE instance...  my experience calling LabVIEW DLLs inside of LabVIEW has been spotty because of the types of things you're talking about.  Just yesterday I had an instance where:

• dll was "unchecked" (LV 2023)
• EXE was "checked" (Also LV 2023)

But the latest runtime installed on my system was 2024.

So the EXE ran, it even called the DLL successfully... but then crashed when it tried to unload it... Actually took me a little while to figure out what the issue was... it was a new EXE, and I had forgotten to uncheck that guy.

Overall -- I absolutely agree... it get's pretty messy pretty quick.

[rolfk]

LabVIEW DLLs executed in LabVIEW will run inside the LabVIEW host environment if the runtime version is compatible. Otherwise it will be instantiated in its own runtime engine and all parameters will be marshaled between the two environments.

What consists compatible runtime version can get ugly very fast. If both versions are the same it will always run inside the host LabVIEW version. Otherwise it depends if the DLL was built with “Run in future versions”. If so and the LabVIEW host is newer it will run in the host runtime. Otherwise it will run in its own compatible runtime, which still may be newer than the version of LabVIEW the DLL was build with.

Being compatible with future versions is nice as it makes the requirement for installations of the right runtime less stringent but there is simply no way NI could guarantee that such a program will work perfectly the same unless you agree that NI will have to do compatibility tests which each new version with exponentially increasing effort. Needless to say that exponential grow gets very quickly impossible to pay for.

[jyoung8711]

---

@rolfk wrote:

LabVIEW DLLs executed in LabVIEW will run inside the LabVIEW host environment if the runtime version is compatible. Otherwise it will be instantiated in its own runtime engine and all parameters will be marshaled between the two environments.

What consists compatible runtime version can get ugly very fast. If both versions are the same it will always run inside the host LabVIEW version. Otherwise it depends if the DLL was built with “Run in future versions”. If so and the LabVIEW host is newer it will run in the host runtime. Otherwise it will run in its own compatible runtime, which still may be newer than the version of LabVIEW the DLL was build with.

Being compatible with future versions is nice as it makes the requirement for installations of the right runtime less stringent but there is simply no way NI could guarantee that such a program will work perfectly the same unless you agree that NI will have to do compatibility tests which each new version with exponentially increasing effort. Needless to say that exponential grow gets very quickly impossible to pay for.

---

This is interesting, and jives with what I was expecting.

However, it doesn't match my experience in the what I experienced yesterday.

In that case I had:

• EXE compiled in 23.3 with "run in future versions" checked
• dll compiled in 23.3 with "run in future versions" unchecked
• LV 2024Q1 installed on the system.

When I called the EXE, it ran fine.  When the EXE called the dll, it executed as expected, but then hard-crashed (at what I think was the dll unload -- all functionality had successfully executed already) with a "MemoryManager.cpp" error.

When I changed the EXE build spec to have "run in future versions" unchecked, everything ran just fine.

In the original (crashing) case, I would have expected the dll to be invoked in it's own instantiated runtime version safely, but it caused a crash.  The resolution/workaround I arrived at is fine, but the experience itself is a little troublesome / confusing to me.

[rolfk]

---

@jyoung8711 wrote: In the original (crashing) case, I would have expected the dll to be invoked in it's own instantiated runtime version safely, but it caused a crash.  The resolution/workaround I arrived at is fine, but the experience itself is a little troublesome / confusing to me.

---

That the DLL got instantiated in its own runtime doesn't mean that it can not crash. Something in the marshalling got apparently messed up. Marshaling is a very intense and tricky thing to do and anything, but really anything that does not go perfectly fine will easily cause fatal crashes.

Basically this whole version compatibility problem is very complex and you can easily end up in the situation to be damned if you do and damned just as well if you don't but in different ways. The version compatibility was a much requested feature but it simply quadrupled the potential problems you can run into, and the according compatibility burden in LabVIEW.