Where's the version stored in a vi's binary file?

[crelf]

This question is a little off-the-wall, but let's propose a hypothetical situation: some engineer was working on an old project - the code was in version 8, and the idiot engineer opened the code and edited it in 8.2. He/She then saved it in version 8.2. Now he/she didn't change all the VIs in the project, but it's a significant number of them. Rather that going through the process of opening them all up in 8.2, back-saving them to 8, he/she would like to scan the folders for files edited after a certain date and then, using some magical binary file editor, change the version stored inside the VI back to 8. The engineer knows that there's been no functionality added to the VI that depends on LabVIEW 8.2, and is kinda hoping that NI didn't change the VI binary format radically between 8 and 8.2, so is it possible to just change the few bits in the binary file that brand the VI's version? If so, anyone know where that would be? I'm (errr, the foolish engineer) could really use some help

[Darren]

I wouldn't bet on the binary source not changing significantly between two x.y versions of LabVIEW. Perhaps two x.y.z versions...

But if I were in your shoes, I would write a utility that uses the Get VI Version method (of the Application class) and the Save.For Previous method (of the VI class) to programmatically accomplish the task.

-D

[Justin Goeres]

QUOTE(crelf @ Feb 6 2008, 03:29 PM)

This question is a little off-the-wall, but let's propose a hypothetical situation: some engineer was working on an old project - the code was in version 8, and the idiot engineer opened the code and edited it in 8.2. He/She then saved it in version 8.2. Now he/she didn't change all the VIs in the project, but it's a significant number of them. Rather that going through the process of opening them all up in 8.2, back-saving them to 8, he/she would like to scan the folders for files edited after a certain date and then, using some magical binary file editor, change the version stored inside the VI back to 8. The engineer knows that there's been no functionality added to the VI that depends on LabVIEW 8.2, and is kinda hoping that NI didn't change the VI binary format radically between 8 and 8.2, so is it possible to just change the few bits in the binary file that brand the VI's version? If so, anyone know where that would be? I'm (errr, the foolish engineer) could really use some help

Bah. When I brought up a similar idea (admittedly, in a different context ) I got made fun of.

My thrashing around in the linked thread led me to believe the important bits were stored somewhere near the end of the file, but once I realized I was chasing a flea with an elephant gun I stopped looking. Semi-seriously, if you have an old (pre-OS X or Classic-enabled) Mac lying around you might be able to figure it out pretty quickly using good ol' ResEdit. That's just the kind of waste of time I could get behind, if my old Mac wasn't broken.

[PJM_labview]

I think to even have a chance of this working, you will have to strip the compile code as well (so opening the VI would required a recompile).

I think you should go with Darren solution.

PJM

[gleichman]

Wouldn't it be easier to just go back to the old version stored in source code control server?

[crelf]

QUOTE(Darren @ Feb 6 2008, 06:29 PM)

But if I were in your shoes, I would write a utility that uses the Get VI Version method (of the Application class) and the Save.For Previous method (of the VI class) to programmatically accomplish the task.

Ooooo - I'd forgotten about that method :)Thanks for everyone's suggestions, I'll do it Darren's way (errr, I mean, I'll suggest the foolish engineer do it Darren's way )

QUOTE(gleichman @ Feb 7 2008, 09:09 AM)

Wouldn't it be easier to just go back to the old version stored in source code control server?

Yes, yes it would, but was actually a very good reason that this update wasn't covered in our source code control system (most of the project was, just not this update). The reason? I can't tell you :ninja:

[Stinus Olsen]

QUOTE(crelf @ Feb 7 2008, 04:32 PM)

Ooooo - I'd forgotten about that method :)Thanks for everyone's suggestions, I'll do it Darren's way (errr, I mean, I'll suggest the foolish engineer do it Darren's way )

Nah .. thats doing it the easy way ..poke around a bit in the end of the VI file and you will find your way (offset) to the version section of the file,

do a bit reversing on that one too and you will end up with the lowest version of LabVIEW that are able to load the file!

Now get to it! .. ;0)

[Rolf Kalbermatter]

QUOTE(Zerobite @ Feb 12 2008, 03:41 PM)

Nah .. thats doing it the easy way ..poke around a bit in the end of the VI file and you will find your way (offset) to the version section of the file,

do a bit reversing on that one too and you will end up with the lowest version of LabVIEW that are able to load the file!

It's not that trivial. The VI format is really a lot like the Macintosh resource file format. And that means the offset of particular information can be more or less anywhere in the file, depending on the order of how the resources were written. Admittingly if the VI was safed from scratch in a particular version, then the relative locations of those resources will be all in the same order, but for upgraded versions that is definitely not necessarily the case as new resources might get added during the upgrade and they may end up behind the already stored resources.

However the other suggestion of using ResEdit on the Macintosh is probably not very likely to fly either. ResEdit expects the resources to be in the resource fork of the file, but since that doesn't exist on other platforms than the Mac LabVIEW puts its resources into the data fork. Also the LabVIEW resource format is very similar to the Macintosh resource format but it is not exactly the same. So even if you get ResEdit to pick up the data fork I'm not sure it could read that information without choking on them somehow.

Also I'm surprised by Darrens suggestion that he suspects the file to not change much between versions. It's a binary format after all and even a single byte change somewhere is quite likely to be fatal when LabVIEW tries to load a VI. So no just changing the earliest possible LabVIEW version resource in a way is a quite likely case of messing up the VI so badly that it can not be loaded anymore by LabVIEW.

Darrens suggestion however is also the only sane one in that respect. (Except of course the other ones like using source code control and such, but that is sometimes not very helpful after the facts )

Rolf Kalbermatter

[Darren]

QUOTE(rolfk @ Feb 21 2008, 02:28 PM)

Also I'm surprised by Darrens suggestion that he suspects the file to not change much between versions. It's a binary format after all and even a single byte change somewhere is quite likely to be fatal when LabVIEW tries to load a VI. So no just changing the earliest possible LabVIEW version resource in a way is a quite likely case of messing up the VI so badly that it can not be loaded anymore by LabVIEW.

I probably shouldn't have used a double-negative in my response. I was trying to say that the format will almost certainly change significantly between two x.y versions (i.e. 8.2 to 8.5). It almost always changes between two x.y.z versions too (i.e. 8.2.0 to 8.2.1), but I'm pretty sure there has been at least one instance in the past where an x.y.z upgrade did not result in a version bump in the save format, which means the save format *could* be the same between those versions.

But regardless, I still advocate using the Get VI Version method over any sort of sifting of the binary itself.

-D

[Rolf Kalbermatter]

QUOTE(Darren @ Feb 21 2008, 03:59 PM)

I probably shouldn't have used a double-negative in my response. I was trying to say that the format will almost certainly change significantly between two x.y versions (i.e. 8.2 to 8.5). It almost always changes between two x.y.z versions too (i.e. 8.2.0 to 8.2.1), but I'm pretty sure there has been at least one instance in the past where an x.y.z upgrade did not result in a version bump in the save format, which means the save format *could* be the same between those versions.

But regardless, I still advocate using the Get VI Version method over any sort of sifting of the binary itself.

-D

A those double negatives!!! One should not assume :-) Well rereading it I see what you really meant, probably need to go to bed. It's been a long day.

Rolf Kalbermatter

[orko]

I'm still trying to figure out why anyone would ever want to revert back to buggy ole LV8.0 hehe...

[Rolf Kalbermatter]

QUOTE(orko @ Feb 21 2008, 05:58 PM)

I'm still trying to figure out why anyone would ever want to revert back to buggy ole LV8.0 hehe...

Very good point, orko!

But our beloved crelf (I mean his ahem collegue) probably has his obscure reasons.

Rolf Kalbermatter

[crelf]

QUOTE(rolfk @ Feb 22 2008, 02:15 AM)

But our beloved crelf (I mean his ahem collegue) probably has his obscure reasons.

All of my reasons are obscure! Just ask anyone here at V I Engineering!