[Python-Dev] DLL in the system directory on Windows.

Mark Hammond mhammond@skippinet.com.au
Thu, 6 Apr 2000 23:53:10 +1000


> > The answer is that Perl extensions never import data
> from the core
> > DLL.  They always import functions.  In many cases,
> they can hide
> > this fact with the pre-processor.
>
> This doesn't answer my question.  My question is how they
> support COM
> without having a DLL in the system directory.  Or at least I don't
> understand how not importing data makes a difference.

By not using data, they can use either "delay load", or fully
dynamic loading.

Fully dynamic loading really just involves getting every API
function via GetProcAddress() rather than having implicit linking
via external references.  GetProcAddress() can retrieve data items,
but only their address, leaving us still in a position where
"Py_None" doesnt work without magic.

Delay Loading involves not loading the DLL until the first reference
is used.  This also lets you define code that locates the DLL to be
used.  This code is special in a "DllMain" kinda way, but does allow
runtime binding to a statically linked DLL.  However, it still has
the "no data" limitation.

> But what DLLs does python16 use that could conceivably be
> delay-loaded?
>
> Note that I have a feeling that there are a few standard
> extensions
> that should become separate PYDs -- e.g. socket (for the
> above reason)
> and unicodedata.  This would greatly reduce the size of
> python16.dll.

Agreed - these were my motivation.  If these are moving to external
modules then I am happy.  I may have a quick look for other
preloaded DLLs we can avoid - worth a look for the sake of a linker
option :-)

Mark.