> 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.