[Import-sig] RE: pythonpath and COM support

[Mark Hammond]

[Greg writes]

> > Exactly - when a Python COM object is being used, the .exe may well be
> > something created by VB, and no where near the Python
> directory.  Thus, the
> > full path to the .exe will be useless, but the full path to Python1x.dll
> > will be OK.
>
> The path to the python15.dll won't help us -- it is sitting in System32.

Except I thought we were discussing how to get python15.dll _out_ of
System32?

> There might be some weird voodoo in the COM stuff that can alter the load
> path (AppPath?) for a COM server DLL, but I've never looked into it. I
> seem to recall that it exists and allows the NT Loader to look in
> specified directories for the dependent DLLs. For example, a COM server
> registration says "use MyComExtension.dll for the COM server" and it also
> says "use C:\Program Files\Python\DLLs" as an additional path. If it
> exists, that would be nice.

Damn - yes - I believe you are correct. [Although my recollection is that
the AppPath exists for executables rather than COM objects - eg, we could
set up an AppPath for "Python.exe", but not for arbitary COM object names]

Lets say "MyVBApp.exe" uses a PythonCOM object.  This PythonCOM object can
happily point to a full path - eg "C:\Program Files\Python\Pythoncom15.dll".

Now, Pythoncom15.dll obviously links against Python15.dll.  However, the
search path rules dictate that the "path of the .exe" is used to locate the
extra DLLs.  So even though Python15.dll is in the same directory as
Pythoncom15.dll, Windows will not search that directory for Python15.dll -
it will search the path that "MyVBApp.exe" lives in, but not the paths that
other DLLs were found in.

*sigh* - I should have remembered that without Greg's prodding :-(  OTOH, I
really should test this out - maybe Windows is a little smarter than the
rules say it is.

Mark.