Same code build twice => diff binary

  • Thread starter Thread starter Viviana Vc
  • Start date Start date
V

Viviana Vc

Hi all,

I am using Win2k, VS. NET 7.1 (MS development Environment 2003 7.1.3088)
and I noticed that by building the exact same code twice the generated
binaries are different (not much, but they are). To be sure I tried a
simple application like void main(){} and 2 times rebuilding the project
gets 2 different binaries.

Has anybody any clue why this happens?
Could I somehow change a setting or something to remove those diff (I
mean from the same code to get identical binaries)?

Thanks in advance,
Viv
 
Viviana said:
Hi all,

I am using Win2k, VS. NET 7.1 (MS development Environment 2003
7.1.3088) and I noticed that by building the exact same code twice
the generated binaries are different (not much, but they are). To be
sure I tried a simple application like void main(){} and 2 times
rebuilding the project gets 2 different binaries.

Has anybody any clue why this happens?
Could I somehow change a setting or something to remove those diff (I
mean from the same code to get identical binaries)?
Click to expand...

Re-building a small program, I only see a couple bytes difference around
offset 0xe8 in the file. This is a timestamp that the linker puts in the PE
header that tells when the image was linked.

-cd
 
But I also get the obj different so I thought that this is a compiler
option not linker option.

Viv
 
That is sad :( I am having an update feature in my product, and because
of the timestamp it will have to update all the binaries, even though
they are identical.
 
Maybe a different way of handling updates is required, not based on
binary compares.

Cheers

Russell
 
Viviana said:
But I also get the obj different so I thought that this is a compiler
option not linker option.
Click to expand...

There may well be timestamps in the .obj files as well, but if so, they
don't influence the output of the linker.

-cd
 
Viviana said:
That is sad :( I am having an update feature in my product, and because
of the timestamp it will have to update all the binaries, even though
they are identical.
Click to expand...

Or -- you could use a PE editor and manually change the timestamp to a value of
your liking...
 
Viviana said:
That is sad :( I am having an update feature in my product, and
because of the timestamp it will have to update all the binaries,
even though they are identical.
Click to expand...

But that is the point, they are not identical as the two
binaries have a different PE information.

Why not change the diff program so that it skips over the PE
header, in which case it would report no differences in the
binaries.

Jussi Jumppanen
Author of: Zeus for Windows (All new version 3.92 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl programmer's editor"
Home Page: http://www.zeusedit.com
 
Any tool I could use for skipping the PE header?
As I said I already tried to change the time stamp in the PE header
using a PE editor, but still there are 2 diffs between the exes
(initially there were 3).

Viv
 
I could of course, but the problem is like this: I have let's say a
binary that uses common code from other libraries, like some header
files, so would be hard to know when to change the version number ...
There are many developers working on the same header files, so hard to
check if something has changed in order to change the version number.
 
In message <[email protected]> of Mon, 14 Jun 2004 12:42:52
in comp.os.ms-windows.programmer.misc, Viviana Vc
[Poster wants an executable built twice to compare equal.
Poster cross-posted to 5 newsgroups and should consider fewer. The same
poster started another thread in 9 newsgroups. This is unlikely to be
productive. Some knowledgeable people would ignore the posting on that
basis. They are a LOT better than corresponding multi-postings.]
I could of course, but the problem is like this: I have let's say a
binary that uses common code from other libraries, like some header
files, so would be hard to know when to change the version number ...
There are many developers working on the same header files, so hard to
check if something has changed in order to change the version number.
Click to expand...

If you use a project file (Microsoft's term for Makefile) appropriately,
your product will be rebuilt if and only if a contributing component
changes. Version control systems can help in organising this.

Your problem is in a class which is not reasonably soluble with the sort
of technique you hope to apply.

If I wanted to solve your problem, I would find or write a PE dumper - I
can propose no suitable URL - and then compare files with boring things
filtered from the comparison. Hopefully, this will work.

I usually take the line that files with different dates or sizes are
different. This is a fairly conservative approach. It is highly likely
that the "same" thing can not be built on my machine and yours or even
twice on mine. The same river can not be viewed twice. ;)
 
Back
Top