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