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

WinMerge PE .dll .exe comparison plugin

Coders and would-be coders alike, this is the place to talk about programming.
Post Reply
techie
ultra-n00b
Posts: 4
Joined: Wed Dec 14, 2005 11:31 am
Been thanked: 5 times

WinMerge PE .dll .exe comparison plugin

Post by techie »

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
Rahly
VVIP member
VVIP member
Posts: 411
Joined: Thu Aug 05, 2004 10:17 am
Been thanked: 341 times

Post by Rahly »

why is something like this even needed?
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)
User avatar
aluigi
VVIP member
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:

Post by aluigi »

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?
techie
ultra-n00b
Posts: 4
Joined: Wed Dec 14, 2005 11:31 am
Been thanked: 5 times

Post by techie »

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.
User avatar
Dinoguy1000
Site Admin
Posts: 786
Joined: Mon Sep 13, 2004 1:55 am
Has thanked: 154 times
Been thanked: 985 times

Post by Dinoguy1000 »

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.
Welcome to Xentax!

Rules | Requests | Wiki | Discord

If you run across a post that breaks the rules, please report the post - a mod or admin will handle it from there.
Post Reply