From: Thomas H. <th...@py...> - 2005-04-28 11:28:06
|
"Jimmy Retzlaff" <ji...@re...> writes: > mi...@pc... wrote: >> Whilst we're on the subject.... perhaps you could enlighten me as to >> how the OS path works > > There are lots of details and options. For DLLs that are linked to an > app (i.e., an import lib for the DLL was linked for example to an > extension module) I would assume it uses the approach described in the > Remarks section of: > > http://msdn.microsoft.com/library/en-us/dllproc/base/loadlibrary.asp Yes. All this is known as DllHell, and MS constantly invents new things and complicates the rules to work around the problems. >> Can you add a directory to the windows search path (for this program) >> by doing: >> >> os.environ['path'] += ';' + dir_name > > You could probably do this for DLLs you use ctypes to load and maybe > even DLLs used by extension modules as long as you did it before the > first import of those extension modules, but I don't think it would work > for DLLs used by the interpreter itself unless you did it in a batch > file just before loading the exe. I believe Windows loads the DLLs which > have static references in the exe before any code in the exe is > executed. I don't understand exactly how py2exe's stub is structured and > how it hands control off to the interpreter, but if it dynamically loads > the interpreter (via LoadLibrary[Ex]) instead of being statically linked > to the Python DLL, then it might have a chance to alter the search path > before loading the Python DLL which in turn causes things like > MSVCR71.dll to be loaded. py2exe up to version 0.5 linked to the Python import library, in other words the python dll must be on the system search path otherwise the executable would not start. In the upcoming 0.6 version, py2exe uses LoadLibrary at runtime to load the python dll. Before any Python code can be executed - of course. Thomas |