Darren's Weekly Nugget 05/10/2010

[jyoung8711]

---

@rolfk wrote:

---

@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.

---

This all is reasonable.  I didn't dig in further in the dll/exe example.  There could easily be some interface issues there that are swept under the rug if it runs in same LV runtime instance, but cause issues if it needs to go between versions.  My expectation is that the runtimes should typically match here (in this case).

To be clear: I think that this version compatibility has been a HUGE boon for PPL based solutions.  It's simplified version migration for our solutions greatly.

Generally, I've been burned a couple of times with this, so my tendency now is to be deliberate in that setting... The one thing that surprises me a bit, is that it defaults to "on"... it seems like the "safer" option would be to uncheck it... but I'm sure there's good reason for that decision.

[wiebe@CARYA]

---

@rolfk wrote:

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.

---

I'm not sure what you mean by "both versions are the same". If this option is on, the build version seems irrelevant.

Both the exe as the dll will run in the highest RTE available, independent of each other.  

In my experience, a dll will also run in the highest RTE available in source.

Here's what happened to us:

LV20 source, LV 20 dll (option tagged), everything works for me (20 vs 20).

LV20 exe (option tagged), LV 20 dll (option tagged), everything works for me (20 vs 20).

LV20 exe (option tagged), LV 20 dll (option tagged), works on PC with 23 RTE (23 vs 23).

LV20 source, LV 20 dll (option tagged), does not work on PC with 23 RTE (20 vs 23).

LV20 source, LV 20 dll (option untagged), works on PC with 23 RTE (20 vs 20).

LV20 exe (option tagged), LV 20 dll (option untagged), does not work on PC with 23 RTE (20 vs 23).

LV20 exe (option untagged), LV 20 dll (option untagged), works on PC with 23 RTE (20 vs 20).

So you're basically stuck with keeping this option off. If it's on, the source will fail as the dll uses the newest RTE.

Of source, this is only a problem if the dll attempts VI server methods with host references (which is a practical way to have them communicate).

I think (always one more bug) something like this:

As it is, there's no combination that always works. To make both source and exe work, the option should be off. But then the option is completely useless, as you have to rebuild for each version of LabVIEW. With the proposed option, the options can be turned on and will work for source and exe, and the dll can be used in newer versions of LabVIEW (as is the intent of the idea).

I really hope this is different for ppls. I haven't checked...

[wiebe@CARYA]

BTW, sorry for derailing this thread.