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

[Martin von Loewis]

> 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