Mark Hammond <mhamm...@users.sourceforge.net> added the comment: I'm wondering if, in practice, extensions which need a manifest can have the manifest being generated completely by the linker - ie, I expect that in most cases where something other than the CRT or MFC is needed in the manifest, the author will want to specify an explicit manifest file rather than one generated by the linker.
And worse, those extensions are going to be screwed anyway - the fact the manifest remains at all will mean they probably fail to load for reasons already discussed in this bug. IOW, not having a manifest at all is about the only way to ensure the module will be loaded correctly. Re adding a manifest back in - I've struck the exact same problem with pywin32 - any DLLs which are "entry points" into Python need to have a manifest - eg, pythoncomxx and a few other pywin32 ones. This left me with a dilemma for pythoncom - as it is both an "entry-point" (ie, COM loads that DLL) and a regular Python module, I simultaneously needed a manifest (to work when loaded by COM) and needed to *not* have one (to work when loaded by Python). My solution has been to introduce another DLL with a manifest and have COM servers register using that. This strategy seems to be working well in all my tests. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7833> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
