Binary differences occur in the exe generated by building the same code

[kthirano123]

Binary differences occur in the exe file generated by building the same code.

I want to make sure the generated exe file is the one build with the specified code.

Is there a good way?

[JimB.]

I wouldn't mind being told I'm wrong, but AFAIK there aren't any settings to make LabVIEW generate deterministic builds. (i.e.; the ability to produce byte to byte identical binary output across compilations from identical inputs.)

[rolfk]

One thing that definitely would cause binary differences is if you have the default behaviour of autoincrementing the version number on each build. The version resource is part of the binary file, so will always cause a change in the executable if it changes.

Aside from that there is always the chance that something in the executable gets compiled slightly different depending on your current system configuration. But that is not really much different in other build environments.

[crossrulz]

---

@rolfk wrote:

One thing that definitely would cause binary differences is if you have the default behavior of autoincrementing the version number on each build. The version resource is part of the binary file, so will always cause a change in the executable if it changes.

---

There are also timestamps inside of the executable, I believe for when the VIs were built into the executable.  In the past, we have also observed this and other unknown differences with other software compilers.

[rolfk]

---

@crossrulz wrote:

---

---

There are also timestamps inside of the executable, I believe for when the VIs were built into the executable.  In the past, we have also observed this and other unknown differences with other software compilers.

---

That's because the VIs inside an executable (without the diagram and other unnecessary overhead) are stored in a ZIP archive structure. And each ZIP archive file entry also contains a DOS time for the file creation date, and potentially extra data per file entry that also stores the creation date, modification date and last access date in unix time format. That's a by product of using the zlib library with the ZIP extension library for packing everything into the exe. In old times LabVIEW put an LLB into the exe which also stored timestamps for file entries but only supported one directory level. So, no, the binary code does not contain timestamps, but yes the file structure does as it uses the ZIP archive format to store the VI resources.

[kthirano123]

Thank you for answering.
I understand why Binary makes a difference.
Is there a way to prove that the exe file was generated from the same code?

[rolfk · Accepted solution]

---

@kthirano123 wrote:

Thank you for answering.
I understand why Binary makes a difference.
Is there a way to prove that the exe file was generated from the same code?

---

Not easily. There is a private VI Server method that returns a UID for a VI. This is just a number generated as hash from all the relevant binary information in a VI. NI uses that internally in some tools to determine if a VI has changed and the entire build product may require rebuilding.

You could write a tool that calculates this UID for each VI in your Build target and stores it somewhere. However this is serious work to do and there are many difficulties in writing this. The first one would be to use VI server to enumerate all the files in your build target and then their dependencies. Then run through each with this method and store all the UIDs somewhere. Then you can run through it again and compare the stored UIDs with the one returned by this node.