version-number dependency in extensions (was Re: ConfigParser module in 1.52 is buggy?)

[Neil Hodgson]

Mark:
> In a nutshell, when a Python COM object is registered, a reference to
> "pythoncom[xx].dll" is added to the registry.  If this is placed in the
> Python directory itself, the pythoncom[xx].dll is found fine, but this DLL
> references python[xx].dll.  Even if python[xx].dll lives in the same
> directory as pythoncom[xx].dll, Windows refuses to find python[xx].dll.
If
> COM used LoadLibraryEx() to locate the COM dlls, life would probably be
> good.  However, it appears not to.  In the case of Excel for example, the
> "application directory" is clearly not Python's directory.  LoadLibrary's
> search rules prevent python[xx].dll from being located unless it is on the
> path or in the app directory.

    You want to break the implicit loading chain somewhere and then insert
some code to set things up to find and link the right DLL. I had to handle
this for the IntelligentPad COM Control support and fiddled the PATH
environment variable within the process to ensure loading went to the right
directories. Every call from a pad control into the IP runtime required PATH
to be set before the call and restored after (to avoid wrecking the
containers view of the world). Events had to invert this.

   Now where in Python's DLLs can loading be intercepted? PythonCom[xx] is
possible but it would require dropping the implicit links to Python[xx] and
PyWinTypes[xx] and using explict links and fixups. Not fun. However the
interception could create an earlier stage with a PyStub that just offers
the basic 4 COM entry points, does explict LoadLibrary[Ex]s and forwards the
basic 4 to PythonCom which would have to know to register PyStub as the
server.

   Neil