Python MSVC++ binaries considered evil

[Bengt Richter]

On 24 Jan 2002 02:59:10 -0800, joost_jacob at hotmail.com (J.Jacob) wrote:

>[Edward Diener]> 
>> 
>> Utterly and completely false as regards Borland's C++ Builder and DLLs. 
>> If you have specific examples of this, you should inform the original 
>> poster of the whys and wherfores of such situations, otherwise saying 
>> such a thing is just FUD.
>
>Ok let me make my point more clear.  It is not a problem with
>Borlands' C++ compatibility.  Borland desevers praise for providing a
>good and free C++ compiler.  But you will have to communicate with
>DLLs in the Python installation.   And they are Microsoft DLLs and you
What is a "Microsoft DLL"? How _exactly_ are they different from
Borland DLLs? The interface to a DLL is a standard that the Borland
compiler can and regularly does compile code to meet. Beyond the interface
is what happens in libraries, and there you can get in trouble, but I
don't believe it's a total inevitability.

>will just have to take my word on it since i do not have a link to a
>project that crashes (who would: if you compile your modules to a
>Borland DLL you are in trouble.
That is too broad a statement, and Borland doesn't deserve that. You
can get in trouble in various ways. Borland's docs on creating DLL's
detail many, IIRC. Basically, you have to avoid passing certain kinds
of things between program and DLL. Details of memory allocation and
exception handling will/may be different in Borland vs MS libraries,
so everything has to be accounted for on the proper side when exceptions
happen and destructors get called, etc. But general FUD is not the answer.
The answer is to figure out _exactly_ what is going on (or decide that
you can't/don't-want-to figure it out -- there may be some RTFM time involved),
and then decide whether it's worth fixing.

Borland's tools provide very good detailed control over what's going
on at low levels, so some of this may be learning to use the tool
right to deal with certain differences in defaults. But you have to
know what those are. If you use the same compiler for everything, you
are likely to be using the same defaults everywhere, so you may be
getting away with not knowing about a bunch of stuff.

Additionally, you are talking about C++, but UIAM most of the important
DLLs are straight C, so that should be simpler. I would guess that tying in
to the right memory allocation mechanisms would be the key thing to get right,
but I'm guessing.

>...  Yes you could try to recompile
>-everything- you need with Borland but erm...imagine recompiling
>wxPython, NumPy, pygame, ... often it has even never been done before
>and you are on your own, i tried this route and i can tell you i did
>not like it at all.
I believe you ;-)

>I was hoping the core Python developers would post a reaction as to if
>they have any plans or ideas to free Python from MSVC++.
I'll be interested to hear too. MSVC++ is not cheap, but now with Lippman
heading up MS's C++ activities, it should evolve towards really good standards
conformance, and the IDE is really pretty pleasant. So it's likely to dominate
the Windows world for some time to come.

An alternative build on windows should be possible (maybe someone has done it?)
but it's a lot of work to set up, and volunteers may be more interested in
playing with the language evolution than with the less glamorous Windows
build infrastructure?

Regards,
Bengt Richter