Opening VI's in a hex editor

[Sparkette]

Try the following:

1. Open LabVIEW and create a new VI
   
2. Double-click on the front panel and type some text
   
3. Save the VI
   
4. Open the saved VI in a hex editor
   
5. Search for the text you typed
   

For some reason, the text doesn't appear. Any idea why? Are VI files compressed? If so, can I save it without compression or decompress it?

Any SuperSecretPrivateSpecialStuff that can help?

Edited July 2, 2012 by flarn2006

[Yair]

Are VI files compressed?

In the past no. In recent versions yes. The main reason was probably to speed up loading of code, although that's just a guess.

If so, can I save it without compression or decompress it?

"Probably not" to the first and "maybe, but I personally wouldn't spend any time on finding out how" to the second.

[hooovahh]

Some times I wish there were a more open file format for LabVIEW. I'm not looking to write my own IDE, but to be able to open the vi and determine what kind of objects are in it, or what labels there are without having to open it in a development environment would be nice.

Lets say I want to do some documentation generation on a folder of VIs. Right now I can read the icon, and VI description without needing to start LabVIEW by analyzing the bytes in a hex editor. But what if I want to get the connector pane information? Like what terminals labels are and their data types?

Or what if I use Requirements Gateway and I want to find all labels on the block diagram that start with "Covers: ". Looking at the VI file structure I have not been able to find free labels or text.

Here are the things I have been able to pull out of the VI file structure by analyzing the hex bytes: Main/Internal VI version, LVSR Main/Internal version, flag bits, if a VI is protected, the Window Title, the Help Path, the Help Tag, the VI Description, a 24-bit image of the icon, and a 1-bit image of the icon. I think I can also determine if a VI is re-entrant, and the Revision History if I spent some time.

I thought about releasing my findings on how to pull out this information from a hex dump of a VI in the hopes someone will be able to get more information, and possibly pull out free label text. If anyone is interested I can try to put some time into cleaning it up a bit and releasing it.

I mostly stopped trying to figure out the VI file structure because most of what I want to do can be done with LabVIEW Scripting. I just think that it could be done faster by reading the VI file.

Edited July 2, 2012 by hooovahh

[GregR]

Officially we would encourage you to use the VI Server APIs to do things like this. In some cases we even expose methods on the Application class that can return information about VIs without loading them. The main reason for this stance is because we reserve the right to change our file formats between versions. This is usually either to support new features or to improve performance and has happened many times to various degrees. The last substantial change was to compress several pieces of the VI because CPUs could decompress faster than the larger data could be read from disk. I realize not publishing the format is annoying but it would also be annoying to publish changes to it every release. Try and think that the time it would have taken us to update the documentation is instead being applied to some assume feature.

[hooovahh]

In some cases we even expose methods on the Application class that can return information about VIs without loading them.

I'm very interested in this. I don't want to cause you any work getting an extensive list, but is there an easy way to know what information can be read without loading the VI and all of its dependencies?

Edit: I may have found my answer is it the "Loads the block diagram into memory" remark or note, on the property/invoke node?

Edited July 2, 2012 by hooovahh

[Yair]

I'm very interested in this. I don't want to cause you any work getting an extensive list, but is there an easy way to know what information can be read without loading the VI and all of its dependencies?

I didn't look at the documentation for each method, but the Application class has a few "Get VI XXX" methods which get this data. There might be some others there which don't start with this name. It should be fairly easy to look through all the methods in the class to see this. Of course, at least some of the methods are private, so you would need the supersecret key to see them.

[Darren]

As a general rule, if it's an App method that takes a VI Path as an input, it's giving you VI information without loading the VI into memory. If it's a property of the VI class, then it requires the VI to be in memory.

[Rolf Kalbermatter]

For some reason, the text doesn't appear. Any idea why? Are VI files compressed? If so, can I save it without compression or decompress it?

Yair already answered this mostly. Those resources are compressed using the zlib deflate algorithme, and the reason is indeed speed. CPUs get faster than harddisk interfaces can keep up with, so it's faster to load n bytes and push them through a decompress algorithme than reading 2 * n bytes directly. And no, newer LabVIEW versions can read uncompressed VI files to be backwards compatible, but they do not save uncompressed VIs anymore. To understand the basic VI file format you can take a look at your Milch website and an old inside Macintosh file format book helps too, since LabVIEW uses mostly the Macintosh resource format for its VI files, but that only gives you a very rough overview of where the global things are, not how each of those resources is actually constructed.

[Stinus Olsen]

Some years ago i started out the task to create a VI editor that would let me edit the documentation of a VI without actually opening it (other than for reading the flat binary data of course).

This was a spare-time project but ended up being a sort of in-depth view into the fundamentals of the VI structure. Today i use the resulting class framework for mass documenting VIs

whenever i can (included in my editor is a fix for the long lost CTRL-B bold text combo that NI seems to have forgotten to implement).

The editor is pretty basic but are able to edit/change the VI Icon, History, some window properties, Set/Remove Load-and-go, add/remove VIs from libraries/llb/classes, shuffle around with some security stuff, show VI call hiearchy, create boolean 4-picture controls from gif/png/jpgs, extract VIs from old/new style labview exe's and a bunch of other stuff that are pretty handy when developing lots of LV code

Of course, it's all done through LabVIEW itself

I never thought of releasing the code because it probably violates every law out there, but if you spend a little time with a hex editor (or LV itself) its pretty basic figuring out how VIs are build.

Hint: once you figure out the structure of the VIs, you can use the OpenG function "ZLIB Inflate" to restore the packed sections to their normal size..

[ealekseev]

I have several compiled (runtime engine) labview applications that utilize the company name from many years ago.

Our company changed names and now we need to remove the OLDNAME from the labels in these applications.

 

For apps compiled in 2008 I was able to go into hexedit and manually remove "OLDNAME" without having to recompile the app.

 

For apps compiled in 2009 and later I can't make this change because (apparently) of the zlib compression.

 

We still have full development license of Labview (2011 now, can be updated to 2015) - is there any utility within that would allow us to modify the text of the label?

 

I am trying to avoid having to recompile the app because I think that the source code has been tinkered with and so it woudl be a significant effort to make it work again

not to speak about any changes required by the newer labview versions

 

Thanks

[hooovahh]

I am trying to avoid having to recompile the app because I think that the source code has been tinkered with and so it woudl be a significant effort to make it work again not to speak about any changes required by the newer labview versions

There was never a LabVIEW 2008, not sure what version this worked in but I'm sure it is not a supported feature of LabVIEW.  The right answer is to make a new application.  Editing an EXE is not supported, and by doing so you might be causing unpredictable changes to the software.

 

If you get nothing else out of this, I hope this is a lesson for you to implement a source code control system so you can easily roll back and forward to releases.  You could then get the source which was used for your last EXE, make a branch, make changes, then make a new EXE.

 

But one thing that just occurred to me, does your EXEs have their block diagrams and front panels removed?  If they don't then I suspect you can get tricky and extract the VIs from it, make changes, then build with that source.