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

jay.krell at cornell.edu jay.krell at cornell.edu
Mon Oct 2 01:37:00 EDT 2000


-----Original Message-----
From: Martin von Loewis <loewis at informatik.hu-berlin.de>
To: jay.krell at cornell.edu <jay.krell at cornell.edu>
Cc: python-list at python.org <python-list at python.org>
Date: Sunday, October 01, 2000 11:46 AM
Subject: Import libraries and Borland C (Was: Wholly unnecessary flame.)


>> Oh, there is also the question of "ABI", how the compiler layouts out...
>
>It seems that you are right in the "general" case. In the specific
>case of Borland C++ builder...
>
>As a Unix person, I feel the entire concept of import libraries is
>flawed...

You're mostly right. The import libraries are a little useful though, to
seperate your "build environment" from your "installed environment". They
let the list of stuff you can link against be different than the stuff you
happen to have exported on your system. Import .libs can omit "private"
exports. Import .libs can contain stuff from newer versions (like doing
Win2k development on Win95). Import .libs can munge the names slightly, like
between _CreateFileA at 20 and CreateFileA. I should just be able to point the
linker to %windir%\system32\kernel32.dll though, at least optionally. It'd
be equivalent to dumping the exports into a .def file and making an import
.lib out of that, which is easy and a surprisingly little known technique.
People think the import .libs are so magic and that they are stuck if they
aren't provided -- even forgetting about LoadLibrary/GetProcAddress -- you
don't need import .libs at all.

The pre-VC6 import .lib format also implies that originally surprisingly
very little work was done to support .dlls directly in the linker, but
rather the work was moved into lib. Today lib and link are the same -- look
at the size and imports of lib.exe, dumpbin.exe, editbin.exe. Identical
small size, very few imports, including spawn. They are just stubs that run
link.exe.

>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.


It shouldn't be hard to point Borland C at the VC stdio headers and
msvcrt.dll, but I don't actually know. This isn't a problem of differing
compilers/linkers but of there being no one stdio on the platform with a
frozen binary interface. Even Microsoft gives you three -- libc, libcmt,
msvcrt.lib..

Like Bruce Dodson later said, just don't pass FILE* across .dll boundaries.
Likewise there's no guarantee of being able to delete/free new or malloced
memory across .dll boundaries. At least not w/o specifying and making
available functions to work with them. Or drop down to something more
guaranteed, like CoTaskMemAlloc and CreateFile.

 - Jay





More information about the Python-list mailing list