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

[David Cournapeau]

On Wed, Jul 7, 2010 at 12:26 AM, Thomas Jollans <thomas at jollans.com> wrote:
> On 07/07/2010 12:08 AM, David Cournapeau wrote:
>> On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet
>> <alf.p.steinbach+usenet at gmail.com> wrote:
>>> 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
>
> I'm also rather sure that it's pretty much impossible to have multiple C
> libraries in one process on UNIX, but it's obviously quite possible on
> Windows.

I am not sure why you think it is not possible. It is rare, though.

>
>>  - 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)
>
> Are you telling me that file descriptors (it's a flippin int!) can't be
> passed around universally on Windows??

Yes. The reason why it does not work on windows is because file
descriptor are not "native": in every unix I have heard of, file
descriptor are indexes in a table of the process "structure", hence
can be shared freely (no dependency on the C runtime structures). On
windows, I have heard they are emulated (the native one is the win32
file handle).

David