[Python-Dev] Linking with mscvrt

Paul Moore p.f.moore at gmail.com
Thu Feb 9 13:53:10 CET 2006

On 2/9/06, Neil Hodgson <nyamatongwe at gmail.com> wrote:
> Greg Ewing:
> > But that won't help when you need to deal with third-party
> > code that knows nothing about Python or its wrapped file
> > objects, and calls the CRT (or one of the myriad extant
> > CRTs, chosen at random:-) directly.
>    Can you explain exactly why there is a problem here? Its fairly
> normal under Windows to build applications that provide a generic
> plugin interface (think Netscape plugins or COM) that allow the
> plugins to be built with any compiler and runtime.

This has all been thrashed out before, but the issue is passing
CRT-allocated objects across DLL boundaries. If you open a file
(getting a FILE*) in one DLL, using one CRT, and pass it to a second
DLL, linked with a different CRT, the FILE* is not valid in that
second CRT, and operations on it will fail.

At first glance, this is a minor issue - passing FILE* pointers across
DLL boundaries isn't something I'd normally expect people to do - but
look further and you find you're opening a real can of worms. For
example, Python has public APIs which take FILE* parameters. Further,
memory allocation is CRT-managed - allocate memory with one CRT's
malloc, and dealloacte it elsewhere, and you have issues. So *any*
pointer could be CRT-managed, to some extent. Etc, etc...

As a counterexample, however, I've heard reports that you can do a
binary edit of the DLLs in the Subversion Python bindings, to change
references to python23.dll to python24.dll, and everything still
works. Make of that what you will...

Also, there are intractable cases, like mod_python. Apache is still
built with MSVC6, where Python is built with MSVC7.1. And so,
mod_python, as a bridge, has *no* CRT that is "officially" OK. And
yet, it works. I don't know how, maybe the mod_python developers could

Anyway, that's the brief summary.


More information about the Python-Dev mailing list