[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.