[Python-Dev] Python 2.4 and MSVC 7.1 - extension compatibility

Paul Moore pf_moore at yahoo.co.uk
Fri Jan 16 17:18:05 EST 2004

One of the issues with moving to VC7 for the Python Windows build is
the fact that extensions (or embedding apps) built with MSVC 6 "won't
work" with it.

But I've never actually managed to provoke a crash (not that I've
tried *very* hard, mind). And thinking about the issue a little, I
wonder whether there is a real problem here at all...

A quick check of the DLLs in my Windows\System32 directory shows a lot
which use MSVCRT. Including OLEAUT32, which is one of the key OLE/COM
DLLs. So, presumably, this means that DLLs built with MSVCRT *can* be
used by applications built with VC7. And a Python extension is just a
DLL, with an unusual extension.

So, the question is - is there really any problem with Python 2.4,
built with MSVC7, using an extension DLL built with MSVC6?

The areas where I can see a potential issue are where CRT objects are
shared between the extension, and the Python runtime:

    1. Memory allocated by the extension CRT, and freed by Python
    2. FILE* objects passed from one CRT to the other
    3. Any others?

Memory allocation "should" be OK, if extension writers follow the
rules in the Python/C API manual, section 9.1 - "To avoid memory
corruption, extension writers should never try to operate on Python
objects with the functions exported by the C library: malloc(),
calloc(), realloc() and free()". And no-one ever writes extensions
which violate the rules :-)

There are a series of APIs in the "Very High Level Layer" (PyRun_* and
friends), and some in the PyMarshal series, which pass FILE* objects
about. I wouldn't expect these to be common in extensions.

So, a question - would it be worth documenting which APIs are *not*
supported in extensions built with an incompatible CRT to the one
Python was built with? And if this was done, would it be OK to state
"if you don't use these APIs, you don't have to build your extension
or embedding application with the same CRT as that of Python"?

If it is deemed acceptable to make these sort of guarantees, I'll
volunteer to search out the relevant APIs, and draft a section for the
Python/C API manual. But I don't want to spend the time and effort, if
it's still not possible to say that it's safe to use MSVCRT in those

This signature intentionally left blank

More information about the Python-Dev mailing list