From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
02-26-2013 11:23 PM
Sir Dennis_Knutson,
That is not Gibberish, I just gave him one example that in the reverse process this may casue the problem. Hence this is not possible.
02-28-2013 11:18 AM - edited 02-28-2013 11:48 AM
@paul_a_cardinale wrote:
I don't remember. Try my old VI extractor. I wrote it in LV 10. Probably still works.
So this is intersting. This maybe a topic for another post, but where in the world did you get Open.VI From Buffer Invoke Node? I understand what private methods are, and the "secret" key so I turned them on but I couldn't find Open.VI From Buffer. So I ask where did this come from if it is not from the normal means of finding private methods?
EDIT: Okay so I think this is a deprecated method which is why it doesn't show up in the list.
EDIT2: Okay just one more edit. So I ran this on an EXE I made without debugging turned on, and it couldn't save the VI, it died on the Save Instrument function. But before that everything was fine, so I replaced the Open VI From Buffer, and the Save Instrument, with a Write to Binary File (with a False on Prepend String size). This resulted in me pulling out all of my VIs from my EXE. I could then call these VIs in this version of LabVIEW only (as expected), and I only have front panels to VIs that are being shown in the EXE (again expected).
Quite interesting stuff. The argument could be made that this is just as safe as a DLL, because there is no looking the source, and no way to even know how the VIs work or what they will do, other than the VI name which helps if you name your VIs appropriatly. As a recovery tool this is nice, as a hacking tool it is not. Thanks for sharing it.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
02-28-2013 02:18 PM
I think I originally got the Open.VI From Buffer from LV 7 with scripting & special features turned on.
These days I have a utility that lets me specify the method of an invoke node by typing in the name.
Note that if in your builder you uncheck "Remove front panel" and "Remove block diagram" for all VIs, you will be able to extract the complete VIs from the .exe.
03-01-2013 07:47 AM
Another thing I observed with your VI Extractor is it only extracts VI (which I should have guessed). I extracted all the VIs in an application but I couldn't run the top level VI because it was missing some class files that weren't extracted.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
03-01-2013 09:28 AM
(I hate it when people reply to them selves)
So I can get a reference to the lvclass by using the Property Node on the VI getting the Library. I can then get the path and name of this library but the "Save to Buffer", "Save", "Save For Previous", "Save a Copy", and "Save.Target Library" all will not work in the Run-Time engine. So unless someone else has found a way you won't be able to extract the lvclass file from an EXE.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
03-02-2013 01:51 AM
Well, it sorta worked. All the .ctl files were there and a global vi (no block diagram). Lots of the vis would not load because there was no block diagram so they must not be embedded. I was surprise to see as many files as I did though. Enough to get me started with editing some old code. Thanks.