Browse Prior Art Database

Linking to Potentially Imported Symbols in Windows 32-Bit Environment

IP.com Disclosure Number: IPCOM000118116D
Original Publication Date: 1996-Sep-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 82K

Publishing Venue

IBM

Related People

Fraser, CA: AUTHOR [+4]

Abstract

A method for linking to potentially imported symbols in a 32-bit Windows* (NT/Intel or Windows 95*) environment is described in which annotating the imported symbols is not necessary to make the code more portable to other platforms.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 53% of the total text.

Linking to Potentially Imported Symbols in Windows 32-Bit Environment

      A method for linking to potentially imported symbols in a
32-bit Windows* (NT/Intel or Windows 95*) environment is described in
which annotating the imported symbols is not necessary to make the
code more portable to other platforms.

      In 32-bit Windows, an extra level of indirection is required
when accessing data imported from DLLs.  Programmers have to annotate
the variables in their source code that will be imported, and the
compiler generates different code, involving the extra indirection,
when accessing the variables.  Specifically, when accessing a
variable named "i" that has been annotated, the compiler actually
generates an indirect access through a symbol named "__imp_i".  This
symbol is normally defined in the import library corresponding to the
DLL that exports the "i" variable, and contains a pointer to the real
"i".

This creates two problems:
  o  Annotation is cumbersome, especially when porting from another
      platform since no other platform has such a requirement.
  o  When variables that are not imported are annotated, the
      compiler provides no solution to this problem, and a linker
      error results because the "__imp_i" symbols won't be
      found.  This means that the annotations have to be
      accurate.  If the code being produced may be linked either
      statically or dynamically to variables in N static
      libraries/DLLs, 2**N versions of the code must be built to
      cover all the permutations.

      The present solution shipped in the IBM** VisualAge** for C++
for Windows product solves the problem of annotation by implementing
an option, -qautoimport, that causes it to behave as though all
global variables are annotated.  It, therefore, generates the extra
indirection at all times.  Note that this aggravates the second
problem, whereby symbols that might not be imported are annotated.

      However, the latter problem is solved by enhancing the linker
so that if references to a symbol with a name of the form "__imp_xxx"
are detected, and there is a definition of a symbol "xxx", then the
linker creates an "__imp_xxx" initialized with the address of "xxx".
This permits the user to freely annotate variables that turn out not
to be imported, at the cost of a single extra indirection at runtime.

      The "__imp_xxx" symbol that the linker creates is essentially
a bare-bones version of what would ha...