On 2/9/06, Neil Hodgson <[EMAIL PROTECTED]> 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 comment. Anyway, that's the brief summary. Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
