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

[Mark Hammond]

> I just downloaded and installed it.  I've never seen an
> installer like
> this -- they definitely put a lot of effort in it.

hehe - guess who "encouraged" that :-)

> Annoying nit: they
> tell you to install "MS Windows Installer" first

that should be a good clue :-)

> and of
> course, being
> a MS tool, it requires a reboot. :-(

Actually, MSI is very cool.  Now MSI is installed, most future MSI
installs should proceed without reboot.  In Win2k it is finally
close to perfect.  I dont think an installer has ever wanted to
reboot my PC since Win2k.

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

In the Python world, this qould be equivilent to never accessing
Py_None directly - always via a "PyGetNone()" type function.  As
mentioned, this could possibly be hidden so that code still uses
"Py_None".

One advantage they mentioned a number of times is avoiding
dependencies on differing Perl versions.

By avoiding the import of data, they have far more possibilities,
including the use of LoadLibrary(), 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.

[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?  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.]

Mark.