|Diff Tools email@example.com (2001-03-26)|
|Re: Diff Tools firstname.lastname@example.org (Richard Norman) (2001-03-27)|
|Re: Diff Tools email@example.com (Daniel Dunbar) (2001-03-27)|
|Re: Diff Tools firstname.lastname@example.org (Hans-Bernhard Broeker) (2001-03-27)|
|Re: Diff Tools email@example.com (Dennis Yelle) (2001-03-27)|
|From:||Daniel Dunbar <firstname.lastname@example.org>|
|Date:||27 Mar 2001 23:29:18 -0500|
|Organization:||Virginia Tech, Blacksburg, Virginia, USA|
|Posted-Date:||27 Mar 2001 23:29:18 EST|
> I've encountered a documented problem within Visual C++, that the
> same code will produce different sized executables, when compiled at
> different times or on different machines.
> Now, the problem is, my company wants to be able to see the
> differences between these two executables. If they are just time/date
> stamps, that's fine, but if there is other stuff (memory contents,
> etc) there may be problems, and we have to be able to determine that.
> We'd like a more programmatic way of doing this then using a hex
> editor, but any suggestions are helpful.
has several versions of a program to do diffs of binary files, the
output is not really intended for human consumption, but the size of
it should give you some clue as to the amount of discrepancy between
I would guess (like you) that it is just a time stamp string tucked
somewhere in the symbol table, so you could also try comparing the
output of something like "dumpbin /all".
In the end the output of dumpbin is going to be most valuable I think,
if the size of the executable is changing it could change many of the
relative offsets within the file, confusing xdelta (or someone
comparing the data in a hex editor).
-- daniel dunbar email@example.com
Return to the
Search the comp.compilers archives again.