How do I create a checksum from a (Windows) CVI executable that is useful in the "version control" sense?

[Barry_Wealand]

In other words, this checksum shouldn't change when I build the same source code at a later time with the same build configuration.  I have discerned that the generated binaries are quite different, I assume in some behavior-neutral way, but the differences are extensive nonetheless.  If one were to create a utility for this purpose, would it suffice to simply skip over certain pre-defined areas in the executable that are understood to be different in the binary sense, yet not in the behavioral sense?  If so, how should these areas be identified by this utility?  (Perhaps this is really a question about Windows executables more generally?)

[LuisG]

Hello Barry,

Because of some internal characteristics of the CVI compiler, it is not possible to ensure that two binaries built from the same source, at different times, will be identical. You're correct in that the differences are behavior-neutral, but they're there nevertheless. This isn't necessarily a characteristic of all Windows executables, but it a characteristic of the CVI compiler.

It is also not possible to skip over specific areas of the executable. This an issue that NI is aware of, but it has proven very difficult to address, so far.

Luis

[bigcantaloupe]

Hello,

I have a similar question regarding this issue. I want to generate a checksum for the code and compiler version that I have. I am using labwindows CVI 2020

Doe the latest version of labwindows CVI implement this feature? Or is it still not possible to generate a labwindos CVI checksum with the 2020 version of the software? 

Thanks for your help,

[rolfk]

Do you use version control? If so you should be able to call a command line program for your version control system that can return you the version tag of your repository. Then you can also retrieve the CVI compiler version if you are so inclined, although it may be less important and then store that information into some text file or create a hash from this information or however you want to make it.

A hash of the final build product is not a reliable indicator if you want to base your decision on the actual source code version. Every time the compiler rebuilds the product it will create the same code but parts of the executable image will also contain embedded timestamps that of course change and with that the checksum on the executable will change too. This is not just in LabWindows/CVI like this but pretty much every compiler will do this in some way.

[gdargaud]

Hello, hello,

I think it is enough to disable to option [Build][Target Settings][Embed Timestamp] and then various compilations will be identical. But I've never tested it.

[rolfk]

---

@gdargaud wrote:

Hello, hello,

I think it is enough to disable to option [Build][Target Settings][Embed Timestamp] and then various compilations will be identical. But I've never tested it.

---

Maybe. But it's something that also is caused in Visual Studio. If you recompile a DLL (or EXE) without any change to the code, the resulting binary file is not equal. As such I never considered the EXE or DLL itself as strictly relevant to the actual source code version. If you are strict and pedantic about changing the version information in your project, you can use the version resource in the build product to identify the actual source code version, but I think we all know situations where we did this quick patch and rebuild only to realize later on: "Damn I should have updated the version resource information too!"

For some more restrictive projects where traceability of the used source code version was very important I implemented the method of using a prebuild step that would query the version control status, check that everything was properly committed and then use the repository version tag to put in an additional tag added to the version control resource. This guarantees that the version is traceable to the correct source code.