Browse Prior Art Database

Binary Executable Comparison

IP.com Disclosure Number: IPCOM000123234D
Original Publication Date: 1998-Jul-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 1 page(s) / 44K

Publishing Venue

IBM

Related People

Edwards, IC: AUTHOR

Abstract

When shipping support material for complex program products, the tracking of corrections, or fixes, causes problems. For example, whenever it is required to ship collection service packages (bi-monthly to quarterly), because of the number of fixes that are to be included it is often difficult to understand which built executables have actually changed - a header file may have been modified for example, that is built into half of the product but the change made is only relevant to one executable. In this case the dependency model breaks down.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 69% of the total text.

Binary Executable Comparison

   When shipping support material for complex program products,
the tracking of corrections, or fixes, causes problems.  For
example, whenever it is required to ship collection service packages
(bi-monthly to quarterly), because of the number of fixes that are to
be included it is often difficult to understand which built
executables have actually changed - a header file may have been
modified for example, that is built into half of the product but the
change made is only relevant to one executable.  In this case the
dependency model breaks down.

   One of the main objectives when shipping these collective
service packages is to minimise the amount included.

   Clearly the best way to work out which executables to ship
is to understand which ones have changed.  It may be useful to check
on file sizes, since if the file size has changed then clearly the
executable has.  There are, however, occasions where the file size is
unchanged.  In this case the binary images may be compared
byte-by-byte, but this breaks down as sections of code are often
rearranged and there are imbedded date/time stamps which are of no
relevance.

   The solution described here provides a Binary Executable
Comparison tool which understands the format of the executable,
knowing where imbedded time stamps are placed, what information is
relevant to the operation of the code (including data modifications)
etc and makes a judgement as to whether the executable has R...