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

[Gordon McMillan]

[Guido]

> Someone suggested that COM should not use Tcl/Tk, and then the Tcl/Tk
> DLLs can live in the Python tree.  I'm not so sure -- I can at least
> *imagine* that someone would use Tcl/Tk to give their COM object a bit
> of a GUI.  Moreover, this argument doesn't work for pyexpat -- COM
> apps are definitely going to expect to be able to use pyexpat!

Me. Would you have any sympathy for someone who wanted 
to make a GUI an integral part of a web server? Or would you 
tell them to get a brain and write a GUI that talks to the web 
server? Same issue. (Though not, I guess, for pyexpat).
 
> It's annoying.
> 
> I have noticed, however, that you can use os.putenv() (or assignment
> to os.environ[...]) to change the PATH environment variable.  The
> FixTk.py script in Python 1.5.2 used this -- it looked in a few places
> for signs of a Tcl/Tk installation, and then adjusted PATH to include
> the proper directory before trying to import _tkinter.  Maybe there's
> a solution here?  The Python DLL could be the only thing in the system
> directory, and from the registry it could know where the Python
> directory was.  It could then prepend this directory to PATH.  This is
> not so evil as mucking with PATH at install time, I think, since it is
> only done when Python16.dll is actually loaded.

The drawback of relying on PATH is that then some other jerk 
(eg you, last year <wink>) will stick something of the same 
name in the system directory and break your installation.
 
> Would this always work?  (Windows 95, 98, NT, 2000?)  Wouldn't it run
> out of environment space?  Wouldn't it break other COM apps?  Is the
> PATH truly separate per process?

Are there any exceptions to this:
 - dynamically load a .pyd
 - .pyd implicitly loads the .dll
?

If that's always the case, then you can temporarily cd to the 
right directory before the dynamic load, and the implicit load 
should work.

As for the others: probably not; can't see how; yes.

- Gordon