Sometimes you may need to compare the build images (EXE, DLL, etc.) of thesame project that were built at different times. Since the images containtime and date stamps, a plain file compare reports the differences betweenthe images. You can use the DUMPBIN utility to generate the correct filecompare.
The time and date stamps can be removed from the built image withoutremoving relevant information (code and data) using the /RAWDATA switchavailable in the DUMPBIN utility. Any file compare utility can then be usedon the DUMPBIN output as follows:
DUMPBIN /RAWDATA MyApp.EXE > first.txt
If Myapp.exe is built again at a different time, then use DUMPBIN asfollows:
DUMPBIN /RAWDATA MyApp.EXE > second.txt
You can now compare first.txt and second.txt using a file compare utilitylike:
FC /B first.txt second.txt
Run DUMPBIN in the resident directory of the image. The above procedureapplies to the Release build only because the Debug build records the timeand date stamp on the images (irrespective of /Zi or /Z7) and DUMPBIN doesnot remove this information. If the predefined macros __DATE__ and __TIME__are used in the source, the time and date stamp recorded in the images willnot be removed by DUMPBIN for the Release build. Under these circumstances,you may use the /DISASM switch. However, the /DISASM switch removes thetime and date stamp, as well as the initialized data. This means that youwill not get a true image compare.NOTE
: There is no guarantee that Visual C++ will generate the same binaryimage when building the same source files on successive builds. However,you are guaranteed that the EXE (or DLL) will behave in precisely the samemanner under execution, all other things being equal. Compile and linkoptions and link order play a role in whether two binary images willcompare equally.
If you follow the procedures outlined above and the two images compareequally, then the images are the same. If the two images do not compareequally, then there is still uncertainty as to whether the images are thesame or not.
The resource section of the executable contains date/time stamps. In theresource section of the executable, there is a header for each type ofresource (for example, string table, dialog, icon). Each of these headerscontains a date/time stamp.
Use the Microsoft Portable Executable and Common Object File FormatSpecification from the MSDN Library to alter the date/time stamps so thatthey won't be a factor in the comparison or ignore the resources section inthe comparison.
To identify the section containing the differences, run the WinDiff utilityshipped with Visual C++:
WINDIFF first.txt second.txt
The section containing the differences will start with a line similar tothe following (although the number may be different):
RAW DATA #5
Then, compare this with the output from the following:
dumpbin /headers MyApp.exe
You should find a header that starts with the following:
SECTION HEADER #5 .rsrc name
Because the section number matches the section with the differences in theraw data (in this example, the section number is 5), then the differencesoccur in the section named ".rsrc". This is the name of the resourcesection.
The Export Directory Table has a date/time stamp as well. This is typicallylocated in the .rdata section (Visual C++ 4.2 and later) or the .edatasection (earlier than Visual C++ 4.2). This table exists only if you exportsymbols from the PE image.
The Import Directory Table also has a date/time stamp. This is typicallylocated in the .idata section. One of these tables exists for each DLL towhich the image refers. This date/time stamp is zero unless the image isbound. Once the image is bound, the date/time stamp is set to the date/timestamp of the DLL from where the symbols are imported.
Once again, please refer to the Microsoft Portable Executable and CommonObject File Format Specification in the MSDN Library for information on howto locate the date/time information in an image.