MS VC++ Toolkit 2003, where?

[Alex Martelli]

AIM <Andre_Mikulec at Hotmail.com> wrote:

> The site comes back with a message saying ...
> 
> "The download you requested is unavailable. If you continue to see this
> message when trying to access this download, go to the "Search for a
> Download" area on the Download Center home page."
> 
> Does anyone have any other ideas of where to look?

As suggested to me by David Rushby 10 hours ago,

http://www.microsoft.com/downloads/details.aspx?FamilyId=272BE09D-40BB-4
9FD-9CB0-4BFA122FA91B&displaylang=en

does work.

But, there's another problem -- helloworld.c compiles fine, but linking
doesn't find MSVCRT.LIB -- apparently, the 2.0 .NET Framework SDK does
NOT include this file for x86 (there _are_ a couple of versions under
a64 and some other parallel directory, but I doubt they're good to use
with an x86!-).  As the already-quoted crucial URL
<http://www.vrplumber.com/programming/mstoolkit/> mentions:

"""
# .NET Framework SDK Version 1.1

      Provides the core msvcrt.lib for msvcr71.dll against which to link
your extensions.  This is critically important, as without it you are
going to wind up linking against the wrong run-time and will see crashes
whenever a core object such as a file is shared across run-time
barriers.

      The 2.0 beta also works according to reports, and may be required
to build Numpy 23.6 (whereas 23.1 seems to work without it).
"""

Whether the 2.0 beta also worked, the current definitive 2.0 seems NOT
to work.

Can anybody suggest where to get a Framework SDK 1.1., or any other
legal way to get "the core msvcrt.lib for msvcr71.dll against which to
link your extensions.  This is critically important"...???


And, as an aside...:

It's sure an interesting reflection, that impecunious or thrifty
developers (ones not willing to shell out mucho $$$ to MS for a pro VS
2003) must go through such gyrations as these in order to be able to
build Python extensions on Windows.  I'm sure my Windows-loving
colleagues in the PSF (who got several free copies of VS 2003 from
Microsoft, I believe -- at the time, I had zero Windows installations
and zero interest in Windows, so I didn't sign up for one) have fully
considered this recurring drama, and come to the decision of sticking
with VS 2003 (avoiding any free-as-in-beer compilers such as VS 2005 or
mingw) with thorough and wise deliberation.

The optimizer in the C compiler used to build Python in Windows *IS*
impressive: just today, I ran (and posted to it.comp.macintosh) pybench
on Python 2.4.3 on iBook G4 12", Macbook Pro 2.0 GHz, and Parallels
Workstation VM with Win2000 on the same Macbook -- while the Macbook is
4 times as fast as the iBook, the Windows version, despite the slight
overhead of running under Parallels' virtualization, is an impressive
12%+ _faster_ than the "native" MacOSX Python 2.4.3 (I'm not quite sure
about how good Parallels' virtualization IS, but even if it's as
impressive as a mere 3% overhead, this still means that the Windows
version of Python on identical HW must be at least 15% faster than the
MacOSX version, compiled with gcc).

I can see the stance that such a speedup warrants using Microsoft's
costly VS 2003 and imposing endless gyrations on developers trying to
get it on the cheap -- being one of the latter developers, I'm inclined
nevertheless to grumble, right now, of course;-)...


Alex