Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

[David Cournapeau]

On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet
<alf.p.steinbach+usenet at gmail.com> wrote:
> * sturlamolden, on 06.07.2010 17:50:
>>
>> Just a little reminder:
>>
>> Microsoft has withdrawn VS2008 in favor of VS2010. The express version
>> is also unavailable for download.>:((
>>
>> We can still get a VC++ 2008 compiler required to build extensions for
>> the official Python 2.6 and 2.7 binary installers here (Windows 7 SDK
>> for .NET 3.5 SP1):
>>
>>
>> http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C591-4F97-A900-BEA146E4FAE1&displaylang=en
>>
>> Download today, before it goes away!
>>
>> Microsoft has now published a download for Windows 7 SDK for .NET 4.
>> It has the VC++ 2010 compiler. It can be a matter of days before the VC
>> ++ 2008 compiler is totally unavailable.
>>
>> It is possible to build C and Fortran extensions for official Python
>> 2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's compiler is
>> required for C++ or amd64 though. (Intel's compiler requires VS2008,
>> which has now perished.)
>>
>> Remember Python on Windows will still require VS2008 for a long time.
>> Just take a look at the recent Python 3 loath threads.
>
> Perhaps this all for the good.
>
> There is no *technical* problem creating a compiler-independent C/C++
> language binding.

It is quite hard, though, or would require changes in the API to be
entirely safe. When I asked the question a few months ago to see if we
could fix those issues once and for all for numpy, the most common
answer I got was to pass all the related functions in a structure:
http://stackoverflow.com/questions/1052491/c-runtime-objects-dll-boundaries.

The problem is not compiler, but really C runtimes. By itself, the
issues are not windows specific (using malloc from one C library and
one free from another one is trouble everywhere), but on windows:
 - multiple C runtimes are *very* common on windows
 - many things which are runtime independent on unix are not on
windows (file descriptor: AFAIK, a file descriptor as returned from
open can be dealt with in any C runtime on unix)
 - the MS standard C library is clearly not a priority: win32 specific
objects can be shared across runtimes, but standard C rarely can.
 - the recent manifest concept (which can improve or worsen the
issues)  is incredibly convoluted, and poorly documented (they expect
you to use MS tool and not to try to understand how it works).

David