Craig Holmquist <[EMAIL PROTECTED]> added the comment: > I don't quite understand this issue yet. python26.dll is linked with > a manifest. Isn't that good enough?
Apparently not, at least in my testing. It seems that if a DLL is loaded, Windows will try to resolve its dependencies by looking at that DLL's own manifest; if that fails, Windows will try to resolve them by looking at the EXE's manifest. It won't check other DLLs. From the loader's perspective, it seems like there's no "tree" of DLLs, it's just "EXE loads DLL, EXE loads DLL", even if the loading code is actually in one of the DLLs. I guess I'm more concerned about applications like Apache that only use Python through an external module or plugin; there's no reason the Apache developers would be expected to make this kind of change with the manifests and everything, much less any commercial, closed-source app (say, an IDE or editor that has plugins for several scripting languages). Also, the manifest trick I described as a workaround was only as simple as it was in this case because httpd.exe didn't have any manifest at all; if it already had an internal manifest, working-around this would have been much more gruesome. I understand, though, the value of "xcopy deployment", and I realize that having some means of doing that is better than none at all. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4566> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
