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

[Mark Hammond]

> But, I still don't understand why Perl/COM doesn't need a
> DLL in the
> system directory.  Or is it just because they change PATH?
>
> (I don't know zit about COM, so that may be it.  I
> understand that a
> COM object is registered (in the registry) as an entry point of a
> DLL.  Couldn't that DLL be specified by absolute
> pathname???  Then no
> search path would be necessary.)

Yes - but it all gets back to the exact same problem that got us
here in the first place:
* COM object points to \Python1.6\PythonCOM16.dll
* PythonCOM16.dll has link-time reference to Python16.dll
* As COM just uses LoadLibrary(), the path of PythonCOM16.dll is not
used to resolve its references - only the path of the host .EXE, the
system path, etc.  End result is Python16.dll is not found, even
though it is in the same directory.

So, if you have the opportunity to intercept the link-time reference
to a DLL (or, obviously, use LoadLibrary()/GetProcAddress() to
reference the DLL), you can avoid override the search path.  Thus,
if PythonCOM16.dll could intercept its references to Python16.dll,
it could locate the correct Python16.dll with runtime code.

However, as we import data from Python16.dll rather then purely
addresses, we can't use any of these interception solutions.  If we
could hide all data references behind macros, then we could possibly
arrange it.  Perl _does_ use such techniques, so can arrange for the
runtime type resolution.

(Its not clear if Perl uses "dynamic loading" via GetProcAddress(),
or delayed loading via the new VC6 feature - I believe the former,
but the relevant point is that they definately hide data references
behind magic...)

Mark.