Frankly speaking I'm too busy to carry on with development, but some of you folks may found this proposal to winmerge useful. Perhaps smb. even has a ready piece of code to easily wrap into a plugin. Would be nice to see.
It is about the way how to compare two .dll or .exe PE files with different compile time and perhaps on different machines. I wonder if such tools are already available?
http://sourceforge.net/tracker/index.ph ... tid=363216
Important information: this site is currently scheduled to go offline indefinitely by December 1st 2023.
If you wish to donate to attempt the preservation of tools and software somewhere else before it goes down, check the GoFundMe
If you wish to donate to attempt the preservation of tools and software somewhere else before it goes down, check the GoFundMe
WinMerge PE .dll .exe comparison plugin
- aluigi
- VVIP member

- Posts: 1916
- Joined: Thu Dec 08, 2005 12:26 pm
- Location: www.ZENHAX.com
- Has thanked: 4 times
- Been thanked: 1288 times
- Contact:
Comparing 2 executables is not so simple, but I think that the first step is being sure that the executables are in plain-text (aka not encrypted/compressed) so you must launch them and dump the process memory (although this is probably not enough with some rare strongly encrypted files).
Then you must compare all the various PE sections.
But as the previous post said: what's the real usage ot this thing?
Then you must compare all the various PE sections.
But as the previous post said: what's the real usage ot this thing?
Well, because there is no tool to compare if two different executables compiled on various machines are actually the same. I thought that file format experts may have this tool at hand.
It can be used to detect changes when using various compiler options, like stripped debugging info or symbols, relocation tables etc. Release test could check that no development executables with debug info are packed into release. It could be later used as basis for building database for executable analyzer with hints how to boost compiler options for optimal performance.
It can be used to detect changes when using various compiler options, like stripped debugging info or symbols, relocation tables etc. Release test could check that no development executables with debug info are packed into release. It could be later used as basis for building database for executable analyzer with hints how to boost compiler options for optimal performance.
- Dinoguy1000
- Site Admin
- Posts: 786
- Joined: Mon Sep 13, 2004 1:55 am
- Has thanked: 154 times
- Been thanked: 985 times
I don't claim to be anywhere near an expert on it (or even have a passable knowledge of it, for that matter), but if you want to be sure that a developer's version of an executable doesn't make it into the final product, the easiest method would probably be to have any dev exe's identify themselves as such at runtime. As for boosting compiler optimization, it would seem to me that most compilers worth using have been around for so long, and have undergone so much review and improvement, that they are at least as optimized as you could achieve by handwriting the assembly code yourself.
