BUG: LINK Erroneously Places Functions in Resident Name Table |
Q125800
The information in this article applies to:
- Microsoft Linker (LINK.EXE), used with:
- Microsoft Visual C++, versions 1.0, 1.5, 1.51
SYMPTOMS
The Linker erroneously places the decorated name of a function in the resident name table of a DLL if either of the following is true:
- The function is declared using the __export keyword, and there is no corresponding entry for the function in the EXPORTS section of the project's module definition file (.DEF file).
- The decorated name of the function is listed in the EXPORTS section of the project's .DEF file without a corresponding ordinal value.
According to the documentation concerning .DEF files as well as the documentation on the __export keyword, this is incorrect behavior. This problem may cause the following error to be generated, when it should not cause an error:
LINK Fatal Error L1041: resident names table overflow
RESOLUTION
The 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.
STATUS
Microsoft 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 INFORMATION
We 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 query words: 5.50 5.60 5.60.220 non-resident names
Keywords : kb16bitonly kbgrpdsvc
Issue type : kbbug
Technology : kbVCsearch kbAudDeveloper kbLINKSearch
Last Reviewed: June 4, 2001 |
