Steve Dower added the comment:
> For 2.7, Windows won't be able to find msvcr90.dll without an activation
> context, but that's just an ERROR_MOD_NOT_FOUND OS error.
Actually, it finds the DLL fine and the DLL terminates the entire process when
it fails to detect an activation context. There's #24429 on this, which I
forgot to link to (note that this bug is related to that one, but is much
smaller in scope).
> For 3.4, it shouldn't be using SxS for msvcr100.dll, so the server in
> question must have an unusual configuration. Still, the OSError that gets
> raised should be ignored.
Unfortunately I can't get hold of the error. It's almost certainly a strange
configuration, but it was a commodity, publicly available server where the
configuration is completely outside of the user's control. If we can avoid
crashing when importing stdlib modules regardless of configuration, we should.
> 3.5 built with VC 14 has a separate issue related to this. Due to changes
> from issue 23606, find_msvcrt now returns None. But the TypeError raised by
> CDLL(None) should be ignored here all the same.
And it will be ignored, but when we know it's going to raise, why bother trying
to load the library?
> BTW, in Windows 10 I'm still able to reference CRT functions by name using
> CDLL('ucrtbase'). Are you sure the ultimate plan is to remove the named
> exports?
It looks like on Windows 10 the CRT has switched to the transparent API schema.
My python35.dll does not directly reference ucrtbase, and so it's still
intended to be non-public API, and I still want to discourage its use because
the chance of applications on different Windows versions is too high.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue24634>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
