On 19/12/2012 2:39 AM, Russell Warren wrote:
On Mon, Dec 17, 2012 at 10:25 PM, Mark Hammond
<mhamm...@skippinet.com.au <mailto:mhamm...@skippinet.com.au>> wrote:
The VS2008 redistributables should probably be in the same directory
(ie, msvc*90*.dll in system32) or else they might not be loaded. If
you use the "depends" tool from MS/sysinternals, you will see both
Python itself and pythoncom depend on this.
I ran the depends tool [1] and sure enough, pythoncom27.dll has 3
missing dependencies: MSVCR90.DLL; IESHIMS.DLL; and WER.DLL
Screencap with additional errors here:
http://static.inky.ws/image/3530/Selection_249.png
Strangely, you can see in the screencap that MSVCR90.DLL is picked up
with no issues at all by python27.dll (version issues, maybe?!).
Separate depends analysis of python27.dll does show the other 2 missing.
Actually, assuming you are using a recent pywin32, pycomloader27.dll
should also exist in that dir and should actually be used internally
to load the COM object - this was done primarily as a work-around
for exactly this problem.
Nope - no pycomloader27.dll. Possibly this has not made it into the
latest ActiveState release? I'll try a full install from pip. The only
other python dll was pywintypes27.dll.
Maybe try a stand-alone pywin32 - as mentioned, pycomloader27.dll exists
purely to work around this kind of problem.
What matters is the complexity in how dependent DLLs are loaded - as
the DLL COM object is loaded by some other app, the rules as applied
to that app gets used for resolving DLL references. The COM object
as a .exe is its own app.
Thanks - I think I get it. To paraphrase: You're saying that the
dependency issues still exist in the internals of the localserver.py
LocalServer32 implementation, but dependency loading is deferred and
there are no pre-checks. ie: it may fall flat during runtime at some
point when a dependency is truly needed. For the inproc version, the
windows internals that are loading the pythoncom27.dll are pre-loading
(or pre-checking) dependencies and crashing before it even gets started.
Correct?
Sadly it is a little more complicated than that. Each .exe has its own
"context" for resolving DLLs, and this context is inherited by other
DLLs loaded in the process. The Python DLL (and the pycomloader DLL)
jump through alot of hoops to arrange for their own context to be setup
so we don't depend on the context of the loading .exe. When a inproc
impl is used without pycomloader, the context of the embedding process
is used (which is hard to predict). A localserver impl has its own
context (as it is a .exe) so doesn't strike the same problem.
Indeed, pycomloader exists purely to jump through those context hoops -
all it does is setup the context appropriately then call the pythoncom
DLL (and those hoops can't be put into pythoncomxx.dll or things would
go pear-shaped when that DLL is loaded by python itself).
Cheers,
Mark
Thanks very much for the tips. I'll try and chase down these weird DLL
issues now.
Russ
[1] For anyone else landing here, 'depends' is available here (not
sysinternals): www.dependencywalker.com <http://www.dependencywalker.com/>
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
