BUG: LINK Erroneously Places Functions in Resident Name TableLast reviewed: July 18, 1997Article ID: Q125800 |
5.50 5.60 5.60.220
MS-DOS
kbtool kbbuglist
The information in this article applies to:
The Microsoft Linker (LINK.EXE), included with - Microsoft Visual C++ for Windows, versions 1.0, 1.5, and 1.51
SYMPTOMSThe Linker erroneously places the decorated name of a function in the resident name table of a DLL if either of the following is true:
LINK Fatal Error L1041: resident names table overflow RESOLUTIONThe best way to control whether symbols appear in the resident name table or the nonresident name table of a target is to ensure that user defined functions are exported by ordinal. By using the RESIDENTNAME keyword, you can ensure that decorated symbols are placed automatically in the resident name table. By omitting the RESIDENTNAME keyword, you can ensure that decorated symbols are placed automatically in the nonresident name table. Use of the __export keyword does not contribute to placement of the symbols in the target image at all.
STATUSMicrosoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.
MORE INFORMATIONWe can easily demonstrate the linker's behavior in all cases in the following way: If four functions are declared as such:
void __export DllFunc1(void); void __export DllFunc2(void); void DllFunc3(void); void __export DllFunc4(void);And the .DEF file for the project contains the following EXPORTS section:
EXPORTS _DllFunc1 @1 RESIDENTNAME _DllFunc2 @2 _DllFunc3 ; note there is no entry for _DllFunc4_DllFunc1 is placed in the resident name table as it should be, but _DllFunc3 and _DllFunc4 are erroneously placed in the resident name table. _DllFunc2 is placed in the nonresident name table as it should be. NOTE: If controlling placement of symbols in the resident and nonresident name tables is an issue, export the functions using the methods shown for _DllFunc1 and _DllFunc2. This is the recommended approach.
|
Additional reference words: 5.50 5.60 5.60.220 non-resident names
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |