Did You know?

[proximableu]

Did you know :

that if you choose multiple top-vis in AppBuilder, when building dlls, you will have multiple dll-functions?

that if you change the name of application, that you build, from *.exe to *.llb, you can browse it from vi-server? (it works with exe extention too), so you can build plug-ins without worying to add a "dynamycal-vi" in build time?

That you can run fine LabVIEWs .dlls with rundll32.exe?

But, I WISH, That you can store text files (constants, ini settings etc ) IN you application, just mimic you extention to *.vi ?

/ProximaBleu

[proximableu]

BTW, But, if you just want to access ReadOnly you text file and it should be inside you application, make blank vi, make string constant, and put whatewer you want in it, mark it with some token, than you can access file from within .llb or .exe, just for using ReadCharactersFromFile.vi, and search for you token to extract whatewer you put in..

Heh..

[Jim Kring]

Did you know that if you change the file extension of <LabVIEW>\applibs\lvapp.lib from "lib" to "exe" that it behaves just like a built LabVIEW application with no VIs inside of it?

[Kurt Friday]

Hi All

SciWare have just released AppLauncher for free.

AppLauncher allows you to run LabVIEW source code under the Runtime Engine, it uses vi server to launch the top level vi from a llb.

Source code and examples are provided, feel free to modify it and build upon it.

http://www.sciware.com.au/free_stuff.htm

[aledain]

AppLauncher allows you to run LabVIEW source code under the Runtime Engine, it uses vi server to launch the top level vi from a llb.

2765[/snapback]

Doesn't this breach the license agreement? I didn't think you're allowed to "build" executables without the Application Builder, and by definition running the source code using the runtime would bypass the build and be doing just that.

cheers, Alex.

[Kurt Friday]

Thanks Alex

I

[Jim Kring]

Doesn't this breach the license agreement? I didn't think you're allowed to "build" executables without the Application Builder, and by definition running the source code using the runtime would bypass the build and be doing just that.

cheers, Alex.

2768[/snapback]

When you run VIs using the Run-Time engine, your not "running the source code". The only part of a VI that runs is the executable code. It just happens that VIs can have several parts contained within the *.vi file -- the LabVIEW application builder normally removes the diagram (source code). The LabVIEW Run-Time engine is really just LabVIEW w/o the compiler and editor -- it behaves almost identically. As long as all VIs in your "applications" hierarchy have been saved, they are compiled. All you need is the Run-Time engine of the same LabVIEW version, and your application will run. The "LabVIEW Application Builder" does not really "build executables", it simply aggregates your applications VI hierarchy into an LLB and then prepends an executable stub (<LabVIEW>\applibs\lvapp.lib) onto the front of the main LLB file and changes the extension of the file to EXE.

Per the NISLA (since LV 7.0), NI reserves the right to make the sole determination as to whether your application is "authorized"; and, any application that competes with a National Instruments product is not authorized. So... does the "AppLauncher" breach the license agreement? No, not until NI tells you that it does (but they probably will). But, the fact that the AppLauncher is designed and distributed for the expressed purpose of bypassing the LabVIEW App Builder, which could hurt sales of the LabVIEW Professional Version and App Builder add-on doesn't help.

Interestingly, any LabVIEW application (executable) can be used to run any other LabVIEW application (assuming that all VIs in the hierarchy are saved in the same version of LabVIEW). All you need to do is run the executable from the command-line, passing it the path of your application's top-level VI.

-Jim

[Mike Ashe]

Did you know that if you change the file extension of <LabVIEW>\applibs\lvapp.lib from "lib" to "exe" that it behaves just like a built LabVIEW application with no VIs inside of it?

2757[/snapback]

Per the NISLA (since LV 7.0), NI reserves the right to make the sole determination as to whether your application is "authorized"; and, any application that competes with a National Instruments product is not authorized.  So... does the "AppLauncher" breach the license agreement?  No, not until NI tells you that it does (but they probably will). 

Interestingly, any LabVIEW application (executable) can be used to run any other LabVIEW application (assuming that all VIs in the hierarchy are saved in the same version of LabVIEW).  All you need to do is run the executable from the command-line, passing it the path of your application's top-level VI.

2776[/snapback]

Interesting. If you combine these two then you would not be using the application builder, so in that case could you argue that you were not bound by the NISLA? Yes, it's a nitpicky way to make the argument, but considering the unbounded breadth of the NISLA clause...

On another note, has anyone ever tried to add a VI to an EXE after it was made? We know that you can change *.exe to *.llb and then treat it like any other llb (but you don't have diagrams). Could you then add a VI to that *.llb, change the extension back to *.exe and run and have access to the new VI?

And obviously, the next question is, could you exchange an old VI for a new one of the same name? And finally, is there any reason that you could not do this programmatically? Might prove to be an interesting way to push updates out to distributed executables. It would also be a pretty serious security flaw....

I think I'll go experiment a bit.

[Jim Kring]

Interesting. If you combine these two then you would not be using the application builder, so in that case could you argue that you were not bound by the NISLA?  Yes, it's a nitpicky way to make the argument, but considering the unbounded breadth of the NISLA clause...

Since VI files contain executable code which may be run using the LabVIEW Run-Time Engine, they are themselves "applications". This means that NI could say that your VI files are not authorized to be distributed for use with the LabVIEW Run-Time engine. This is one good reason why we need to be able to distribute VI source code seperately from the bytecode.

[Jim Kring]

And obviously, the next question is, could you exchange an old VI for a new one of the same name? And finally, is there any reason that you could not do this programmatically? Might prove to be an interesting way to push updates out to distributed executables. It would also be a pretty serious security flaw....

Or insert "wrapper" VIs into the hierarchy that intercept and operate on data as it flows into and out of subVIs? Sure, you can.

Heres another trick... insert keys into an app's INI file that enable VI Server TCP-IP access. Now you can open a remote application reference to the app and peek/poke into the control/indicator data of its VIs (those that have FP's).

[jpdrolet]

And obviously, the next question is, could you exchange an old VI for a new one of the same name? And finally, is there any reason that you could not do this programmatically? Might prove to be an interesting way to push updates out to distributed executables. It would also be a pretty serious security flaw....

I think I'll go experiment a bit.

3269[/snapback]

If I remember correctly, you can rip the internal LLB into file VIs using the library manager, make any replacements/wrapping and rebuild the application.

[Wolfram]

Did you know that if you change the file extension of <LabVIEW>\applibs\lvapp.lib from "lib" to "exe" that it behaves just like a built LabVIEW application with no VIs inside of it?

2757[/snapback]

Did you know that it is also possible to use the VIs inside an executable in new VIs. Simple use the "Select a VI" to drop into the diagram. So, it is possible to read out data from sub-VIs that the author of the executable want to never appear. You can read even the connectors and context help of the dropped VIs. This works even, if the front panel of the dropped VI was removed. Hence, spy out of software is supported well.

I find that issues very bad.

[Ale914]

Did you know that if you open a labview "compiled" .exe file with a text editor you can see all constanst names and values?

So if you have a subVI with a constant named "password" simply with notepad you can find its label in compiled code and retrive its value. very very bad.

I'm developing a little utilite that change all constants\controll\indicators name in compiled code with an ID. this works fine.

Bye,

Alessandro.

[Rolf Kalbermatter]

Did you know that it is also possible to use the VIs inside an executable in new VIs. Simple use the "Select a VI" to drop into the diagram. So, it is possible to read out data from sub-VIs that the author of the executable want to never appear. You can read even the connectors and context help of the dropped VIs. This works even, if the front panel of the dropped VI was removed. Hence, spy out of software is supported well.

I find that issues very bad. 

5139[/snapback]

Why? The only sure why that your super findings can not be stolen by anyone with bad intentions is to lock them in a safe, throw away the key and destroy any notes and software code you happen to have done during development. Once you distribute it, there will be always a way to get at that information more or less easily. So you may just as well forget the pretense to have your code securely distributed and live with it.

Give me a compiled DLL and unless it is code which on puropse has been obfuscated with self modifing assembly routines, I have the complete code reverse engineered in less time than it would take to just figure out how to call diagramless VIs to get at sensitive data. Does this mean that anybody using Visual C, Borland C, Delphi or whatever does not have anything to hide in comparison to a LabVIEW developer?

Cool down and see the things in respective.

Rolf Kalbermatter

[Rolf Kalbermatter]

Did you know that if you open a labview "compiled" .exe file with a text editor you can see all constanst names and values?

So if you have a subVI with a constant named "password" simply with notepad you can find its label in compiled code and retrive its value. very very bad.

I'm developing a little utilite that change all constants\controll\indicators name in compiled code with an ID. this works fine.

Bye,

Alessandro.

5140[/snapback]

You do have a little problem here. The actual control label information is stored in a different place than the data a control contains. Just because you find the word "password" in the binary data, does not mean that the actual default password data is directly adjecent to this string. In fact it is not. LabVIEW stores its files in a resource format very similar to the MacOS resources. That while a logical format, separates different aspects of a VI in seemingly unrelated areas in the file.

So the fact that you see a password string in a file would indicate that you might try to search any other string to try to figure out which of them could be a password but it will not show you easily which of the numerous strings in a VI file is the password.

Of course, why would you store a password in a VI? Passwords are to be chosen by a user and remembered by those users. Storing them anywhere basically makes passwords quite useless anyhow and you could simply forget about the hassles altogether for everyones benefit. All my VIs which contain a password control would not give you any password at all. Their default data is an empty string and it is meant to be a parameter passed from higher level functions and ultimately coming from the user itself.

Any passwords I might store in an application (usually in a config file) are stored as a one way hash such as MD5 or SHA of the original password. On verification the user enters his password and the same hash is calculated and if the calculated hash does not match the stored hash, the password was not valid and access is denied. The actual password however is never stored at all. This means that if the user forgets it not even I can get it back, but its either that or you don't need a password verification at all.

Rolf Kalbermatter

[WMassey]

Thanks to some of the information found in this thread I have found an easier way (for me at least) to use the application builder in my distribution of LabVIEW applications. I don't think that sharing this method and the VI's I have used to implement it runs afoul of of NI's App Builder but i wanted to get others opinions about this before posting the VIs. You still need the App Builder to turn the important VI into an executable file, and I am not posting that file as an executable. That VI, when combined with an INI file telling it what VI to in turn run and an LLB (or folder) of all necessary VI's that make up a project, will run the project's VIs on any system that has the appropriate LabVIEW RunTime engine installed.

Rather than repeating a bunch of stuff I have already written, here is a README file that I have included with the VIs:

Build the "Run VI.vi" into an EXE file using the NI Application builder and the included .BLD script file.

(you may want to change the "Run VI" icon along the way).

If your project contains just one top-level VI and no dynamically-called VIs then skip the next step.

Create a top-level container VI and put all top-level VIs, external VIs started with the VI server or dynamically-called VIs into this top-level container VI and save it.

Using the top-level container VI (or just the top-level VI if no container is required) select

File --> Save With Options --> Application Distribution and save the entire hierarchy to an LLB file or a folder of VIs. It's up to you whether or not you let the save process strip out the block diagrams.

Place the "Run VI.EXE" and the new LLB (or folder of VIs) into a common "Program" folder. Use the included "Find CallLibrary References.vi" utility with the top-level container VI to get a list of all the DLL files used by the hierarchy. Add copies of all the specialty DLLs (i.e., the ones not normally found included in the LabVIEW runtime or otherwise on the target machine) that are required to a DLL folder in the "Program" folder.

Zip up the "Program" folder and move it to the target machine. Install the appropriate LabVIEW RunTime engine on the target machine. Create a shortcut to the "Run VI.EXE" and give it a name that reflects the function of the project. Move a copy of the shortcut to where ever is appropriate (desktop, Start>Programs, ...).

Execute "Run VI.EXE" - it will expect you to browse to the top-level VI which you want to be executed. It will save that VI's path in a "Run VI.INI" file for subsequent runs and it will then start the VI that was identified for execution.

If everything was done right the project will be up and running.

You may ask, "Why not just build the project using the application builder in the first place?" My reason is that doing it this way I only have to run the app builder once, every time a new version of LabVIEW is released. Complex projects can be difficult to get right using the app builder, often requiring a considerable amount of fussing with its setup to get things working correctly. This has saved me a lot of aggravation when it has come to trying to get the app builder to include the correct dynamic VIs, external VIs and VI front panels (my attitude has been "include them all, disk space is cheap these days.") The "Run VI" app build on the other hand is trivial since it involves only one VI.

Distributing applications this way also allows me to update all the distributed runtime-only projects just by dropping a new LLB (or even individual files) onto the target machines. Besides updates to the VIs themselves, the most I might have to change on the target might be the INI file that identifies the first VI to run. Once you have a working version on a target machine, it is relatively easy to copy it to other targets.

One other note about the "Run VI" VI. I purposely built it without any calls to any external subVIs so that it would both be self-contained (easy App build) and that there would never be any question of a conflict with any VI that might appear within the project it was calling.

This is what I am proposing that I submit (as a zip file):

Should I go ahead and add the zip file? Any interest? Is it legal enough?