Linux VI with Runtime Engine Only

[tst]

---

wiebe@CARYA wrote:

In windows, typing the vi's name on the command line starts the vi in the runtime engine.

---

I didn't know that the RTE could register the VI type in Windows (although I know LV itself does). Are you sure that it was the RTE and not the Windows executable?
Anyway, as suggested, you can simply write a small application which will accept the VI path as a command line parameter (or, if no parameter was entered, using a file dialog) and will simply use VI server to run the VI. Then, all you will need to do is find someone who can build the app for you and save each VI you want to use in your Linux copy.

Giving the user the option of choosing whether to use the RTE or have a stand-alone app is probably not a very viable solution at this point, because it probably has a lot of dependencies by now. Before 8.2, you could run your code without installing the RTE (if it didn't require stuff like VISA or DAQmx) by placing the executable in the same place as the RTE DLLs. In 8.2, I think that was changed.

In any case, the way to get proper platform independence is probably not to allow the RTE to compile the VIs, but to use a VM like Java or .net (at least if my understanding of the CLR is correct) and I suppose it's not impossible that NI is considering this as Linux and Mac are becoming more popular.

[Wiebe@CARYA]

"tst" <x@no.email> wrote in message news:1171127408586-476414@exchange.ni.com...
Wiebe@CARYA wrote:In windows, typing the vi's name on the command line starts the vi in the runtime engine.




I didn't know that the RTE could register the VI type in Windows&nbsp;(although I know LV itself does). Are you sure that it was the RTE and not the Windows executable?Anyway, as suggested, you can simply write a small
Interesting question. I'm not sure if the VI type is registered. I did see some websites where you can download VI's, and they say you can download the rte to try them out. I think even NI has this somewhere on there website. I'll have to try it out someday.



application which will accept the VI path as&nbsp;a command line parameter (or, if no parameter was entered, using a file dialog) and will simply use VI server to run the VI. Then, all you will need to do is find someone who can build the app for you and save each VI you want to use in your Linux copy.


Giving the user the option of choosing whether to use the RTE or have a stand-alone app is probably not a very viable solution at this point, because it probably has a lot of dependencies by now. Before 8.2, you could run your code without installing the RTE&nbsp;(if it didn't require stuff like VISA or DAQmx) by placing the executable in the same place as the RTE DLLs. In 8.2, I think that was changed.


In any case, the way to get proper platform independence is probably not to allow the RTE to compile the VIs, but to use a VM like Java or .net (at least if my understanding of the CLR is correct)&nbsp;and I suppose it's not impossible that NI is considering this as Linux and Mac are becoming more popular.
They are better off if they include the compiler part in the run time engine. Perhaps as an option if the code is big. They already have this code, and the result is the same. They also lose the requirement that the vi and the rte have to be the same version, a 7.0 vi will run on the 7.1 rte.


Regards,


Wiebe.

[Wiebe@CARYA]

"tst" <x@no.email> wrote in message news:1171127408586-476414@exchange.ni.com...
Wiebe@CARYA wrote:In windows, typing the vi's name on the command line starts the vi in the runtime engine.




I didn't know that the RTE could register the VI type in Windows&nbsp;(although I know LV itself does). Are you sure that it was the RTE and not the Windows executable?Anyway, as suggested, you can simply write a small application which will accept the VI path as&nbsp;a command line parameter (or, if no parameter was entered, using a file dialog) and will simply use VI server to run the VI. Then, all you will need to do is find someone who can build the app for you and save each VI you want to use in your Linux copy.




Well, you where right. You need an executable to run the vi's, even under windows. The good news is, there doesn't need to be anything in the executable! If you create an exe without a main vi, you can start any vi from the command line using the exe.


We also tested this with LabVIEW 6.1 under Linux (we have an app.builder for 6.1/Linux). And we got the same result! Although we used created an executable with a vi in it.


So if you create an exe with a vi in it, and start the exe from the command line with a second vi as command line option, the original main vi is not even started! So there is our vi loader. No need for fancy dynamic loading stuff:


"mainvi.exe test.vi" starts the test.vi, not mainvi.vi, both under windows/LV7.1 and Linux/LV6.1.


Now we only have to beg for a Linux/LabVIEW 8.2 executable with nothing in it!


Regards,


Wiebe.

[shoneill]

"mainvi.exe test.vi" starts the test.vi, not mainvi.vi, both under windows/LV7.1 and Linux/LV6.1.

Wow.

I did not know that.

Who needs the application builder now? (Only joking NI 😉 )

Shane.

[tst]

---

wiebe@CARYA wrote:

So if you create an exe with a vi in it, and start the exe from the command line with a second vi as command line option, the original main vi is not even started!

---

I'm hoping there is no serious security risk in this (e.g. since you called the mainvi.exe, the main.vi hierarchy is loaded even though it is not run and then the writer of the other VI can play around with it), even though that would be of little importance in my systems.

[Wiebe@CARYA]

"tst" <x@no.email> wrote in message news:1171302009208-476920@exchange.ni.com...
Wiebe@CARYA wrote:So if you create an exe with a vi in it, and start the exe from the command line with a second vi as command line option, the original main vi is not even started!


I'm hoping there is no serious security risk in this (e.g. since you called the mainvi.exe, the main.vi hierarchy is loaded even though it is not run and then the writer of the other VI can play around with it), even though that would be of little importance in my systems.


By default the diagrams are removed from the vi's in the executable, so there is no risk there. But a vi run by the exe could call the sub vi's inside the exe, which might be a risk.


I used this constuction a lot in one application. It was critical that the application wasn't shut down. By putting a test/diagnostic vi on a memory stick, I could do diagnostics without shutting down the application. Also, the diagnostic code was not on the system, so I knew for sure the normal users could never access is. This is a really great usage for this trick.


Another one is if a dynamic sub vi can't be loaded by the executable. Changes are, the error handling is not accessable for the end user (because it should never fail). This happens when standard ni vi's are used in the dynamic vi, but not in the executable (like picture control vi's). Starting the failing sub vi with the exe result in a more extended error report, indicating exactly was vi's are missing. Saved me a lot of time.


I just hope NI is never going to change this.


Regards,


Wiebe.

[shoneill]

I still can't quite get my head around this.....

Does this mean that a built EXE can actually load other VIs at startup into the SAME application space?  This would mean that a finished (?) EXE can still be expanded under certain circumstances....

What happens if a VI is loaded in this way which has the same name as a VI used by the EXE?  Is it replaced? does it generate an error?

This is quite a feature IMHO.  And one I knew absolutely nothing about.

Shane.

[tst]

If I understand this correctly (and I've only done one quick test) when you run your executable with a path to a VI as a command argument, the RTE will simply load that VI instead of your top-level VI, not along side it, so the hierarchy is not loaded at all. My suggestion that the VI will be in the same application space was only to provide one example of how this could potentially be a security risk.

---

Wiebe@CARYA wrote:

By default the diagrams are removed from the vi's in the executable, so there is no risk there.

---

As mentioned, the risk would not be in someone being able to access your code, but with someone being able to use other VIs. In any case, as I said, the discussion on this point is rather academic, at least for me, since it is of little importance in our current applications.

[shoneill]

"If I understand this correctly (and I've only done one quick test) when you run your executable with a path to a VI as a command argument, the RTE will simply load that VI instead of your top-level VI, not along side it"

Thanks for the clarification Tst.

Shane.

[waldemar.hersacher]

---

@shoneill wrote:
Does this mean that a built EXE can actually load other VIs at startup into the SAME application space?

---

If you would build two applications <builds>\AppA.exe and <builds>\AppB.exe you have two ways to load additional VIs into the running application.

<builds>\AppA.exe will contain a VI AppA_viA.vi which is not in the hirarchy of the already loaded VIs (top level or dynamic) then <builds>\AppB.exe will have two ways to start this VI.

You can open a reference to AppA.exe with "Open Application Reference" and use <builds>\AppA.exe\AppA_viA.vi as path in "Open VI Reference" together with the reference of AppA.exe. This will load the VI into the application space of AppA.

You can use <builds>\AppA.exe\AppA_viA.vi as path in "Open VI Reference" and not connecting the Application reference input (meaning your local application). This will load the VI from AppA.exe into the application space of AppB.