[Import-sig] RE: pythonpath and COM support

[Greg Stein]

On Sat, 5 Feb 2000, Mark Hammond wrote:
>...
> > Couldn't pythoncom15.dll etc. live in /DLLs? Or are they
> > loaded by other C extensions (using LoadLibrary instead of
> > PyImport_x)?
> 
> pythoncom15.dll and pywintypes15.dll (infact, anything I release with the
> extension ".dll") is used as a "standard DLL".  There exists the possibility
> that a .exe will have an implicit reference to one of these .DLLs.  So
> unless they are in the same path as the executables, or on the %PATH%, they
> will not be found.

To be quite explicit about what Mark means here:

  If we have DLL foo.dll and an application or *another* DLL links against
  foo.dll, then we must place foo.dll on %PATH%. Current "design
  preference" in Windows is to avoid changing PATH, so the DLLs go into
  the System or System32 directory.

What DLLs go in there, and why?

  python15.dll: any Python extension module is going to link against this.
                Thus, when the extension is loaded (from wherever!), this
                module must be found.

  pywintypes15.dll: most of the Python/Win32 DLLs links against this for
                    some basic types.

  pythoncom15.dll: Python/COM extensions will link against this for
                   various pieces of functionality (base classes and
                   support functions)

> > > * The path searching code would need to use the location of
> > Python1x.dll,
> > > rather than the .exe, to locate the PYTHONHOME.  This would not
> > be a huge
> > > change, but necessary none-the-less.
> >
> > Um, why? Especially if they're the same directory ;-)?
> >
> > Oh, because of COM (and exposing python15.dll as a COM
> > server)?
> 
> 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.

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.

I don't see that we can avoid putting those DLLs into the System directory
without some special provision for modifying the NT Loader's paths.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/