memory. This is basically a link operation.
In Windows, a dynamic-link library (
) file has no dangling references. Instead, an
access to functions or data goes through a lookup table. So the DLL code does not have
to be fixed up at runtime to refer to the program’s memory; instead, the code already
uses the DLL’s lookup table, and the lookup table is modified at runtime to point to the
functions and data.
In Unix, there is only one type of library file (
) which contains code from several object
). During the link step to create a shared object file (
), the linker may find that
it doesn’t know where an identifier is defined. The linker will look for it in the object files in
the libraries; if it finds it, it will include all the code from that object file.
In Windows, there are two types of library, a static library and an import library (both
). A static library is like a Unix
file; it contains code to be included as
necessary. An import library is basically used only to reassure the linker that a certain
identifier is legal, and will be present in the program when the DLL is loaded. So the linker
uses the information from the import library to build the lookup table for using identifiers
that are not included in the DLL. When an application or a DLL is linked, an import library
may be generated, which will need to be used for all future DLLs that depend on the
symbols in the application or DLL.
Suppose you are building two dynamic-load modules, B and C, which should share
another block of code A. On Unix, you would not pass
to the linker for
; that would cause it to be included twice, so that B and C would each have their own
copy. In Windows, building
will also build
. You do pass
to the linker for
B and C.
does not contain code; it just contains information which will be used at
runtime to access A’s code.
In Windows, using an import library is sort of like using
; it gives you access
to spam’s names, but does not create a separate copy. On Unix, linking with a library is
from spam import *
; it does create a separate copy.
4.3. Using DLLs in Practice
Windows Python is built in Microsoft Visual C++; using other compilers may or may not
work (though Borland seems to). The rest of this section is MSVC++ specific.
When creating DLLs in Windows, you must pass
to the linker. To build two
DLLs, spam and ni (which uses C functions found in spam), you could use these