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

[Thomas Jollans]

On 07/07/2010 12:38 AM, Martin v. Loewis wrote:
>>>  - 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??
> 
> There are really three things of concern here:
> a) operating system file handles, of type HANDLE (which is an unsigned
>    32-bit value); they are not contiguous, and stdin/stdout/stderr may
>    have arbitrary numbers
> b) C runtime file handles, of type int. They are contiguous, and
>    stdin/stdout/stderr are 0/1/2.
> c) C FILE*.
> 
> OS handles can be passed around freely within a process; across
> processes, they lose their meaning
> 
> It's the data of types b) and c) that cause problems: the CRT handle 4
> means different things depending on what copy of the CRT is interpreting it.

Ah, okay. On UNIX systems, of course, a) and b) are identical.

> 
> It's worse with FILE*: passing a FILE* of one CRT to the fread()
> implementation of a different CRT will cause a segfault.
> 
>> And, as has already been said in this thread, this does not concern the
>> .net developer, or any developer that sticks to managed code, be it
>> .net, CPython, or something-else based.
> 
> Since when is CPython managed code?

It's not managed code in the "runs on .net" sense, but in principle, it
is managed, in that garbage collection is managed for you.