We're using ctypes.windll to load a third-party library. This library uses 'MSVCRT80' and states that it's callers responsibility to free resources. Therefor we've tried using windll.msvcrt.free(pointer) to free resources returned by the external library. This fails as windll.msvcrt is another runtime ('MSVCRT90.DLL' which Python is linked with)

Therefor we explicitly need to load 'MSVCRT80.DLL', but I can't find a way to load this library. I've tried using ctypes.util.find_library('msvcrt80') but this returns None. I guess this is because this function only looks through the path, while the actual library is located at c:\windows\winsxs\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_88e41e092fab0294.

I find it hard to believe that the DLL could be passing on to you resources that you have to free by calling the free in the particular runtime that DLL uses. That is exceedingly difficult to get right. Are you sure that the DLL doesn't export routines for you to call to free resources. If it is as you tell it I think you need to get the vendor to fix their design, or find a different library, or leak resources!
–
David HeffernanSep 13 '11 at 10:50

@David: unfortunatly there is no free-routines exposed by the API. It's horrible, but I think we'll have a hard time getting the vendor to fix this. The main cause why I think so is that this library usually is exposed only through a .NET wrapper - the C++ library is usually not distributed to customers directly.
–
larsmSep 13 '11 at 10:57

Yeuch! One way to get it right is to use the activation context API. That's the clean way to make sure that msvcrt80 is loaded correctly by ctypes. The messy way is to enumerate modules in the process and pick the right one!
–
David HeffernanSep 13 '11 at 11:00

Actually this doesn't work as GetModuleHandleA('msvcr80') returns 0, even though the module has been loaded (it works with other modules, just not the runtime for some reason). However, this pushed me in the right direction; see my answer for the solution.
–
larsmSep 15 '11 at 8:59

Funny, it worked absolutely fine for me. But I tested it with msvcr90 because that's what my Python.exe was linked against.
–
David HeffernanSep 15 '11 at 9:15

I finally figured out a workaround for this problem. After loading the external library, I enumerate over the loaded modules using EnumProcessModules, determine the filenames using GetModuleFileName and reference the correct module and load the free()-function from this runtime.