LabVIEW
Creating password for gvi (LabVIEW NXG)
Solved!
wiebe@CARYA wrote:
@crossrulz wrote:But you can enable debugging, which will allow the block diagrams to be shown.
Didn't know that. So I guess the diagram is still available, and could potentially be copied? I mean with heavy scripting or hacking?
Or just manually reproducing it. Due note that you have to enable the debugging when you build your PPL. I use the debugging option in my PPL builds because being able to probe inside of the PPLs is more valuable to me than any security of the code. They are all internal anyways.
@crossrulz wrote:
wiebe@CARYA wrote:
@crossrulz wrote:But you can enable debugging, which will allow the block diagrams to be shown.
Didn't know that. So I guess the diagram is still available, and could potentially be copied? I mean with heavy scripting or hacking?
Or just manually reproducing it. Due note that you have to enable the debugging when you build your PPL. I use the debugging option in my PPL builds because being able to probe inside of the PPLs is more valuable to me than any security of the code. They are all internal anyways.
It does makes me wonder if the diagram is there only when debugging is on.
Without the diagram (if it is indeed removed), it should still be compatible with 18 and higher when created in 18, right? And across platforms (RT for instance)? IIRC, that is how it has been advertised.
Search LabVIEW like a graph!
wiebe@CARYA wrote:Without the diagram (if it is indeed removed), it should still be compatible with 18 and higher when created in 18, right? And across platforms (RT for instance)? IIRC, that is how it has been advertised.
No diagram = only compiled code = only compatible with that version which it was saved in. However, this did change with 2017 when the "compatible with future LabVIEW RTE" became an option in the build process. I just migrated from 2016 to 2019, so I have not had any attempts to see how well this works. My understanding is that the PPLs with debugging (same for executables with debugging) is that you just have the visual representation of the diagram, but no ability to copy or edit; only probe.
@crossrulz wrote:
wiebe@CARYA wrote:Without the diagram (if it is indeed removed), it should still be compatible with 18 and higher when created in 18, right? And across platforms (RT for instance)? IIRC, that is how it has been advertised.
No diagram = only compiled code = only compatible with that version which it was saved in. However, this did change with 2017 when the "compatible with future LabVIEW RTE" became an option in the build process.
Thought it was 18, but 17 is even better. That was the feature I mend.
I'm not sure if "compatible with future LabVIEW RTE" also means "compatible with other LabVIEW RTE targets", like LVRT.
wiebe@CARYA wrote:I'm not sure if "compatible with future LabVIEW RTE" also means "compatible with other LabVIEW RTE targets", like LVRT.
It does not. We are dealing with compiled code, after all. We can't even run a 32-bit PPL in the 64-bit RTE. Forget RT, Mac, or Linux.
Thank you very much for your discussion.
The solution is very simple: you can create an installer and the user cannot see the diagram anymore.
Your *.gvi looks like this:
@crossrulz wrote:
wiebe@CARYA wrote:I'm not sure if "compatible with future LabVIEW RTE" also means "compatible with other LabVIEW RTE targets", like LVRT.
It does not. We are dealing with compiled code, after all. We can't even run a 32-bit PPL in the 64-bit RTE. Forget RT, Mac, or Linux.
Told NI (years ago) that if they store either the DIFR or LLVM code (but not the diagram heap), it would be possible to recompile, without having the source code...
I was hoping that maybe they finally made this work... Sad to here there's still no solution for this problem.
wiebe@CARYA wrote:Told NI (years ago) that if they store either the DIFR or LLVM code (but not the diagram heap), it would be possible to recompile, without having the source code...
I was hoping that maybe they finally made this work... Sad to here there's still no solution for this problem.
That would be fine as long as we are in the development environment. But if you are going for a plugin architecture for an executable, you have to have fully compiled libraries. That is unless you want the RTE to be A LOT larger by adding in the compiler.
@crossrulz wrote:
wiebe@CARYA wrote:Told NI (years ago) that if they store either the DIFR or LLVM code (but not the diagram heap), it would be possible to recompile, without having the source code...
I was hoping that maybe they finally made this work... Sad to here there's still no solution for this problem.
That would be fine as long as we are in the development environment. But if you are going for a plugin architecture for an executable, you have to have fully compiled libraries. That is unless you want the RTE to be A LOT larger by adding in the compiler.
Yes, for plugins the development environment would be required to compile. But at least it will be possible to distribute something that is usable.
I'm not sure though if the RTE would grow A LOT larger. Maybe just a lot, maybe even just a little. It would not require a full blown compiler, only the LLVM backend. LLVM is like general assembler language. The majority of work has already be done. All that is needed is going from the general assembler to the specific assembler. I'm no expert, but this might not require more then a few hundred kb. I tried to see how big a typical backend is, but there's a learning curve (e.g. I'm not getting it at the moment)...
