The information in this article applies to:
SUMMARYThe header of an executable file created by Microsoft LINK contains two different checksum values. The first, located at offset 12-13h in the old .EXE header, is the complemented checksum of all words in the file. The second, located at offset 08-0Bh in the new .EXE header, is the 32-bit checksum of all DWORD values in the file. The text below describes the process involved to calculate these checksum values. MORE INFORMATIONThe following information that describes calculating the first checksum is from page 122 or the "MS-DOS Encyclopedia" (Microsoft Press): 12-13H (Complemented Checksum) This word contains the one's complement of the summation of all words in the .EXE file. Current versions of MS-DOS basically ignore this word when they load a .EXE program; however, future versions might not. When LINK generates a .EXE file, it adds together all the contents of the .EXE file (including the .EXE header) by treating the entire file as a long sequence of 16-bit words. During this addition, LINK gives the Complemented Checksum word (12-13H) a temporary value of 0000H. If the file consists of an odd number of bytes, then the final byte is treated as a word with a high byte of 00H. Once LINK has totaled all words in the .EXE file, it performs a one's complement operation on the total and records the answer in the .EXE file header at offsets 12-13H. The validity of a .EXE file can then be checked by performing the same word-totaling process as LINK performed. The total should be FFFFH, because the total will include LINK's calculated complemented checksum, which is designed to give the file the FFFFH total.The sample code below shows one implementation of this technique. Note that Microsoft LINK does not correctly calculate the checksum if the linker command line includes the /CODEVIEW or /EXEPACK option switches. However, because the MS-DOS, Microsoft Windows, and OS/2 versions 1.x do not verify the checksum, this behavior does not present a problem under normal circumstances. Microsoft LINK version 5.3 and later do not compute a 16-bit or 32-bit checksum. The reserved bytes in the .EXE header are set to zero. The system uses the old .EXE header checksum when an MS-DOS application runs. However, for any other type of executable file, (an application or dynamic-link library [DLL] for Windows or OS/2 versions 1.x, or a bound application), LINK computes a 32-bit checksum for the new .EXE header. This calculation is only slightly more complicated than that discussed earlier. First of all, the checksum is not the sum of every DWORD value in the physical file. It is the sum of the DWORD values in the executable portion of the file. As other items, like resources, symbolic information, and so on, are added to the .EXE file, the checksum value does not change. To determine the size of the executable file, look at the two words at offset 02h and 04h in the old .EXE file header. Second, the 32-bit checksum is the sum of each DWORD value in the executable file EXCEPT for the checksum itself. Because Microsoft LINK does not perform a complement operation, the result is NOT FFFFFFFFh when all DWORD values are summed. The following code example demonstrates calculating these checksum values. Sample Code
Additional query words: kbinf 5.0x 5.10 5.11 5.13 5.15 5.1x 5.20 5.3x LinkIss 5.50 5.60 no32bit
Keywords : kb16bitonly |
Last Reviewed: October 21, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |