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

[Guido van Rossum]

> > Anyway, ActivePerl installs its DLLs (all 5) in c:\Perl\bin\.  So
> > there.  It also didn't change PATH for me, even though the docs
> > mention that it does -- maybe only on NT?
> 
> In another mail you asked David to look into how Active State handle
> their DLLs.  Well, Trent Mick started the ball rolling...
> 
> 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 avoiding the import of data, they have far more possibilities,
> including the use of LoadLibrary(),

For what do they use LoadLibrary()?  What is it?  We use
LoadLibraryEx() -- isn't that just as good?

> and a new VC6 linker feature called "delay loading".

> To my mind, it would be quite difficult to make this work for
> Python.  There are a a large number of data items we import, and
> adding a function call indirection to each one sounds a pain.

Agreed.

> [As a semi-related issue:  This "delay loading" feature is very
> cool - basically, the EXE loader will not resolve external DLL
> references until actually used.  This is the same trick mentioned on
> comp.lang.python, where they saw _huge_ startup increases (although
> the tool used there was a third-party tool).  The thread in question
> on c.l.py resolved that, for some reason, the initialization of the
> Windows winsock library was taking many seconds on that particular
> PC.
> 
> Guido - are you on VC6 yet?

Yes -- I promised myself I'd start using VC6 for the 1.6 release
cycle, and I did.

> If so, I could look into this linker
> option, and see how it improves startup performance on Windows.
> Note - this feature only works if no data is imported - hence, we
> could use it in Python16.dll, as most of its imports are indeed
> functions.  Python extension modules can not use it against Python16
> itself as they import data.]

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.
Since this way we manage our own DLL loading anyway, what's the point
of delay-loading?

--Guido van Rossum (home page: http://www.python.org/~guido/)