Steve Dower added the comment:
> i'm not following why it's a special case, or why later versions wouldn't
> have the same problem?
The Microsoft C Runtime 9.0 required an activation context to allow multiple
versions to load side by side. This turned out to be more trouble than it was
worth, and so version 10.0 removed that requirement.
> isn't this a problem for any DLLs that the embedding context may have loaded
> that would conflict with DLLs that python depends on?
For any DLL that requires a version specification in the current activation
context, yes. These are fairly rare, but if the DLL checks, then the context
needs to be created for it. (MSVCRT 9.0 requires it and checks - hence the
error when it isn't set up.)
> python's DLL already has the necessary "complete manifest," right?
In theory yes, but apparently it isn't working in this case. It needs more
investigation to figure out why.
> what is the purpose of ctypes.cdll.msvcrt if no one is supposed to use it?
ctypes.cdll.msvcrt doesn't really exist - ctypes.cdll turns it into a
LoadLibrary("msvcrt") call that works because Windows keeps shipping msvcrt.dll
for backwards compatibility (for applications that rely on msvcrt.dll entirely
- not piecemeal).
> there is also "import msvcrt" which is apparently a subset of what you get
> from find_library('c'), so would need the same fix?
No, because this module is built into Python's DLL (and does properly
conversion from Python types to C types, which occasionally differ from the
ctypes conversions). If you've been able to load Python, these functions will
be fine.
> what changed that avoids the problem? perhaps that fix can be applied to 2.7?
Python 3.0-3.2 are also affected, but Python 3.3 and later use newer versions
of the CRT that do not have the manifest requirement. It's been discussed in
the past and has been decided that the official builds of Python will not
change compiler version without a version bump (in this case, 2.7->2.8 would be
required, but has been ruled out).
> innocent ol' me was just trying to import shapely from matlab - they call
> find_library('c') and need the 'free' function. i don't think they ever
> malloc -- they depend on a geos_c.dll, which must do the allocations and is
> built on whatever msvcrt was used for python? probably a better design would
> be for geos_c.dll to export its own free function? but afaiu, geos_c.dll
> comes from a totally different (more legacy?) project, not python related...
Yeah, geos_c.dll really should have exported its own free() function.
find_library('c') is probably the wrong approach here - if geos_c.dll is being
rebuilt with different CRTs at all then the free() function should be added to
it, and if it's truly legacy and is no longer being rebuilt then the version of
the CRT it uses should be loaded explicitly. It isn't automatically getting the
same version as whatever version of Python is running, that's for sure.
> uuid is the only case i can find in the standard libraries that also calls
> find_library('c').
As I said earlier, I'm sure we'd accept a patch to uuid.py to avoid that call
on Windows (or completely remove it - I was sure at one point that ctypes was
considered off-limits for the stdlib). Everything ought to be going through
"import msvcrt" or their own extension modules, and it sounds like they mostly
are.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24429>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
