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 <rep...@bugs.python.org> <http://bugs.python.org/issue24634> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com