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

The manifest in the DLL is stored as resource ID 2. This secondary manifest is used by the loader to create a temporary activation context while python27.dll is loaded. Thus allows it to load msvcr90.dll. 

[python27!DllMain][1] stores the current activation context. This gets reactivated when loading extension modules. Thus when Python 2.7 is embedded, there's no problem loading extensions that depend on msvcr90.dll, such as _ctypes.pyd. 

If _Py_ActivateActCtx and _Py_DeactivateActCtx were exported, they could be called in [_ctypes!load_library][2]. That should solve this problem with using ctypes.CDLL('msvcr90') in embedded Python.

> Windows keeps shipping msvcrt.dll for backwards compatibility (for
> applications that rely on msvcrt.dll entirely - not piecemeal).

Windows itself is the primary user of msvcrt.dll. A Windows 7 installation has over 1500 DLLs and over 350 executables in System32 that depend on msvcrt.dll. Windows developers such as Raymond Chen get a bit annoyed when projects link directly with msvcrt.dll. See [Windows is not a Microsoft Visual C/C++ Run-Time delivery channel][3]. 

> Yeah, geos_c.dll really should have exported its own free() 
> function. 

Each CRT uses a private heap, so mismatching free() and malloc() from different CRTs is wrong. geos_c really should export a free() function. Actually, it really should have the user allocate data.

[1]: https://hg.python.org/cpython/file/15c95b7d81dc/PC/dl_nt.c#l79
[2]: https://hg.python.org/cpython/file/15c95b7d81dc/Modules/_ctypes/callproc.c#l1267
[3]: http://blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx