Import libraries and Borland C (Was: Wholly unnecessary flame.)

[Bruce Dodson]

This is not true.  You can mix and match, as long as you don't export
borland-format resources to MSVC-based consumers.  That is, if memory is
allocated by Borland runtime library, it should freed by the Borland
runtime.  If files are opened by Borland stdio, they should be encapsulated
and not exposed directly to Python.  I used to do this with Symantec C++,
which also uses a different runtime, back before that product went caput.

Bruce

"Martin von Loewis" <loewis at informatik.hu-berlin.de> wrote in message
news:mailman.970426031.22998.python-list at python.org...
> > Oh, there is also the question of "ABI", how the compiler layouts out
> > structs and stack frames and such, but generally compilers follow
> > Microsoft's (or whatever the "native" vendor is) lead in order to be
able to
> > consume windows.h (or whatever platform specific headers/shared
libraries,
> > w/o resorting to something hacky like modifying the headers or providing
> > thunking libraries).
>
> It seems that you are right in the "general" case. In the specific
> case of Borland C++ builder, it appears that Borland always prefered
> to ship their own copy of windows.h and the system import libraries
> (or whatever technology they use to make the functions available).
>
> As a Unix person, I feel the entire concept of import libraries is
> flawed - you should be able to directly link to the dynamic library. I
> believe in Win32, this is actually possible; not sure why the tools
> still insist on import libraries.
>
> But then, even *if* Borland C could link with the VC++ compiled
> python20.dll, you still could not build extension modules with
> it. python20.dll uses stdio, and that comes from
> msvcrt40.dll. However, Borland C has a different implementation of
> stdio. Opening a file with the Borland function, and passing that
> (through python.dll) to a Microsoft function causes a crash.
>
> So to build extension modules with Borland's tools, you need a
> Borland-build Python. Hopefully, people won't call the resulting DLL
> "python20.dll"... Again, it appears that GCC is ahead of Borland C
> here; gcc can happily use MSVCRT as stdio (instead of its "own" cygwin
> library).
>
> Regards,
> Martin
>