[Python-Dev] Switching to VC.NET 2003

[Mark Hammond]

> [Martin v. Loewis]
> > ...
> >
> > In the sample installer, I put python24.dll into TARGETDIR,
> > not into System32Folder. I'd like to keep it that way,
> > as Microsoft discourages deployment into system32. Of course,
> > if there is a good reason to install python24.dll into
> > system32, changing the installer generator to do so would
> > be only a small effort.
>
> We need to hear from Mark Hammond about this, but he's on
> vacation now.  The
> current installer's "non-admin install" option leaves system
> folders alone,
> and works fine for everything I routinely do on Windows.  The point to
> stuffing the Python DLL into a system directory had (IIRC)
> something to do
> with a Windows Service embedding a Python component via COM,
> in which case
> "the virtual command line" that started the service has no
> idea where Python
> might live on the box.  Or something like that -- or
> something not like that
> at all.  That's why we need Mark <wink>.

The underlying issue has to do with embedding Python.  It is most visible
with COM, but exists for any applicaiton that attempts to embed a
'stand-alone' Python installation.  If they also ship Python with their app,
the problem generally is trivial to work around by placing everything in the
same directory, and indeed how py2exe works without putting anything in
system32.

Consider a Python implemented COM object.  Some arbitrary process (eg,
Outlook loading SpamBayes) finds the COM object is supported by loading
pythoncom24.dll (as this DLL has the necessary COM entry points).
Obviously, pythoncom24.dll references symbols in python24.dll.

The problem is that the loading of pythoncom24.dll fails, due to failure to
find python24.dll.  COM itself has done the LoadLibrary() for pythoncom24,
as part of the process outlook.exe.  The Windows documentation for
LoadLibrary() indicates the directory of the DLL being loaded is *not*
searched for dependent DLLs.  As it is not our code doing the LoadLibrary(),
we can not move to LoadLibraryEx().  Thus, the only reasonable solution I
see is for python24.dll to be on the global path.  The easiest way to
achieve that is to copy it to system32.

Another real example:  The win32all installer also embeds Python, via a WISE
extension DLL.  Again, it is WISE itself that loads its extension DLL, and
this DLL has references to Python24.dll.  I could find no way to make this
work, short of insisting that people launch the installation .EXE from the
main Python directory.  (This installer is going to die very soon, but the
underlying issue is not <wink>)

Even a simple .EXE that tries to directly embed Python will have the same
issue - the executable will need to live in the same directory as the Python
DLL, or will fail to load.  In most cases, people will just run it from that
directory, but it doesn't seem a reasonable solution.

XP is supposed to have some new features regarding this, but I have not
looked into it at all.

In summary, we need to ensure that an arbitrary DLL with symbol references
to python24.dll can be loaded by an arbitrary process.

Arbitrarily yrs,

Mark.