BUG: LINK Erroneously Places Functions in Resident Name Table

Last reviewed: July 18, 1997
Article 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

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).

    -or-

  • 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 reference words: 5.50 5.60 5.60.220 non-resident names
KBCategory: kbtool kbbuglist
KBSubcategory: LinkIss
Keywords : kb16bitonly LinkIss kbbuglist kbtool
Version : 5.50 5.60 5.60.220
Platform : MS-DOS


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: July 18, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.