Prev: Python GUI for C program [was: ]
Next: Download Microsoft C/C++ compiler for use with Python 2.6/2.7ASAP
From: Thomas Jollans on 6 Jul 2010 18:26
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(a)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:
> 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
> - 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??
Now Windows programming *really* scares me.
> - the MS standard C library is clearly not a priority: win32 specific
> objects can be shared across runtimes, but standard C rarely can.
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.
> - 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).
From: Martin v. Loewis on 6 Jul 2010 18:38
>> - 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.
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?
From: sturlamolden on 6 Jul 2010 18:41
On 6 Jul, 21:52, casevh <cas...(a)gmail.com> wrote:
> The original version of the Windows 7 SDK includes the command line
> version of the VS 2008 amd64 compiler. I've used it compile MPIR and
> GMPY successfully. The GMPY source includes a text file describing the
> build process using the SDK tools.
It should also be mentioned that the Windows 7 SDK includes
vcbuild.exe, so it can be used to compile Visual Studio 2008 projects
(I'm going to try Python).
From: Martin P. Hellwig on 6 Jul 2010 18:41
On 07/06/10 21:19, sturlamolden wrote:
> On 6 Jul, 21:49, Christian Heimes<li...(a)cheimes.de> wrote:
>> I agree, the situation isn't ideal. I see if I can get in contact with
>> Microsoft's open source team. Perhaps they can keep the download link to
>> VS 2008 EE working.
> It seems the MSDN subscription required to get VS 2008 costs one
> dollar less than $1200. So it does not fit within everyone's budget.
Take in the cost of your operating system, and the ones you want to test
against, perhaps you also like to use office.
Although I am not a windows developer per se, I do use windows XP, 2000
2003, 2008, Vista and 7 for testing. I also use office for all those
clients who think that this is the only format.
1200 USD is actually quite cheap, but then again I didn't pay that
because I am either always been in an academic license (about 70 EUR a
year) or like now in a program for businesses who just start up (free
with my bank as supporting agent). When this 3 year subscription is over
I fall anyway in the cheaper renewals and if not I am sure that there is
some other brand new scheme like they did for the last decade.
Anyway, if you want to provide tools for platforms that are closed
source that means that there are costs for the developer and the client.
Although the cost for MS platforms are reasonable (as a developer and
you know you way around, that means go a couple of times to those free
MS events and it is quite likely you get an MSDN subscription for being
such a good loyal puppy), there are always costs.
If you don't like that better convince your target audience about an
open source operating system, whichever that may be.
From: sturlamolden on 6 Jul 2010 18:57
On 7 Jul, 00:41, sturlamolden <sturlamol...(a)yahoo.no> wrote:
> It should also be mentioned that the Windows 7 SDK includes
> vcbuild.exe, so it can be used to compile Visual Studio 2008 projects
> (I'm going to try Python).
Not sure why I forgot to mention, but we can (or even should?) use
CMake to generate these project files. We don't need Visual Studio for