MS VC++ Toolkit 2003, where?

A

Alex Martelli

So, I thought I'd tool up to let me build and test Python extensions on
Windows (as well as Mac and Linux) -- I'm trying out Parallels
Workstation beta on my new Macbook Pro (and so far it seems to work very
well), I bought and installed a Win2000 Pro on it (since according to
the grapevine it works better than XP in various kinds of virtual
machines, and almost all SW supports w2k anyway -- I also found out that
one exception is the Google Pack, which does require XP), did all the
upgrades (why MS forces you to do 8+ rounds of download-install, from an
off-the-CD win2k SP2 to a fully upgraded win2k SP4, rather than offering
a single-round option, I just don't undersand!), got Python 2.4.3 --
phew, so far so good.

So, I go to <http://www.vrplumber.com/programming/mstoolkit/> and start
following the instructions, beginning with the download of Visual C++
Toolkit 2003... oops! I can't find that download any more at
<http://msdn.microsoft.com/visualc/vctoolkit2003/> -- instead, what's at
that URL is a page explaining that
"""
The Visual C++ Toolkit 2003 has been replaced by Visual C++ 2005 Express
Edition.
"""

Hmmm -- I can't build extensions for the standard build of Python 2.4.3
with VC++ 2005, can I? Express or other, they just use separate and
incompatible C-runtime libraries, I believe.

So -- does anybody know if the 2003-level Toolkit is STILL available for
download somewhere, or can suggest other (legal;-) ways in which I can
build and test Python extensions (with an optimizing compiler --
NON-optimizing ones are right out;-) w/o shelling out beeg moolah to MS?
So far my total investment is about $100 ($40 for Parallels Workstation,
which I preordered after briefly checking out the free-for-1-month beta,
since it worked so well; $60 for the cheapest legal CD+license of w2k I
could find around) -- and I'm not complaining, since the current setup
will still let me TEST many diverse things on Windows; to gain the
further ability of *compiling* Python extensions, I'm not averse to
spending a little more if needed, but certainly not as much as another
$100 (I do prefer free to cheap, but for example the $40 Parallels
product is well worth the money, to me, compared to the free 'Q',
because the latter, while fun to hack around with, was absorbing
countless hours of my time in many attempts to get everything working,
while Parallels essentially "just worked" and saved me LOTS of time).


Thanks in advance for any suggestions! Just to show that I'm an
oldstyle Usenet dynosaur: suggestions in private mail are also welcome
(but my real mailbox these days is at gmail, not as yahoo as the 'From'
header above says), and I will undertake to summarize and post any
suggestions thus received (unless the suggestions' authors request me to
not repost).


Alex
 
A

AIM

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?
 
A

Alex Martelli

AIM said:
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?
Click to expand...

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
 
E

Edward Elliott

Alex said:
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).
Click to expand...

Can you post the complete benchmark results from both systems on the
Macbook? My understanding is that virtualization overhead is not a
constant factor like 3%. Unprivileged instructions run unmodified; only
privileged instructions like hardware accesses get trapped, adding
overhead. Any percentage figure advertised by the manufacturer is most
likely an average over some data set with both types of instructions.

The types of tests mentioned on the pybench site -- function calls,
lookups, exceptions, etc -- shouldn't incur any overhead from
virtualization. It would be helpful to see exactly which tests were faster
and by how much instead of an overall average result.

The differences may be due to factors other than compiler optimizations.
I've heard for instance the OS X virtual memory manager is not particularly
speedy for large data sets. That could give the windows pybench a win on
certain tests regardless of which compiler has better optimizations.

Then you've got issues of whether the compilers are really competing on
equal footing. Were similar options enabled for each build, does each
build represent the best possible optimizations or only the ones the
builder knew about, etc. I think Apple switched to the Intel compiler for
x86 macs, was python built with that or with gcc?

In short, your results are interesting but I'm not sure what to make of
them yet.
 
R

Robert Kern

Edward said:
I think Apple switched to the Intel compiler for
x86 macs, was python built with that or with gcc?
Click to expand...

I'm pretty sure MacTel OS X still uses gcc 4 (although I think there is a beta
version of the Intel compiler available). All of the Python builds floating
around for it certainly use gcc.

--
Robert Kern
(e-mail address removed)

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Alex said:
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"...???
From

http://www.microsoft.com/downloads/...a6-3647-4070-9f41-a333c6b9181d&displaylang=en

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.
Click to expand...

Not sure whether this mark was meant to be sarcastic: but why you don't
want to use mingw to build extensions on Windows, I cannot understand.

Regards,
Martin
 
J

JW

As suggested to me by David Rushby 10 hours ago,

... < huge URL snipped > ...
Click to expand...

Alas, somehow this URL was split in two, and all the kings horses and all
the kings men can't seem to put it back together again (at least in my
browser). Could someone post a tinyurl?
And, as an aside...:

[Those] 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.
Click to expand...

Well, so long as there's a way to get the requisite tools. I'm sure
these Windows-loving colleagues confirmed these "free" tools worked under
WINE, else how would us cheap programmers with Windows-less boxes avoid
sending $$$ to the Great Satan?

Jim Wilson
Gainesville, FL
 
A

Alex Martelli

Martin v. Löwis said:
From


http://www.microsoft.com/downloads/details.aspx?familyid=9b3a2ca6-3647-
4070-9f41-a333c6b9181d&displaylang=en
Click to expand...

Thanks! For the convenience of tinyurl-preferrers:

http://tinyurl.com/5flob

Not sure whether this mark was meant to be sarcastic: but why you don't
want to use mingw to build extensions on Windows, I cannot understand.
Click to expand...

Jocular, but not sarcastic. I have no problems using mingw if that's
what it takes -- the later instructions I saw were those suggesting the
Toolkit instead, so those are the ones I'm trying to follow. What's the
updated URL for the instructions about using mingw instead?


Thanks,

Alex
 
A

Alex Martelli

Robert Kern said:
I'm pretty sure MacTel OS X still uses gcc 4 (although I think there is a beta
version of the Intel compiler available). All of the Python builds floating
around for it certainly use gcc.
Click to expand...

Apple's XCode still uses gcc. The intel compilers are out of beta, and
cost many hundreds of dollars per developer, besides NOT supporting
ObjectiveC, while XCode is still free (as in beer for the GUI parts etc,
as in speech for the underlying commandline tools, though I'm not quite
sure where I'd start looking for the latters' sources if I wanted
them;-).

Edward's request on this thread is eminently reasonable, but I don't
really have time to get and post all the detailed results of pybench
right now - I'll try to get to it this evening.


Alex
 
R

Robert Kern

Alex said:
Jocular, but not sarcastic. I have no problems using mingw if that's
what it takes -- the later instructions I saw were those suggesting the
Toolkit instead, so those are the ones I'm trying to follow. What's the
updated URL for the instructions about using mingw instead?
Click to expand...

Install mingw (an large task in and of itself that I'm not going to go into
here, but look at http://www.mingw.org/) and make sure the bin/ directory is on
your PATH. You will have to edit the gcc specs file to replace "-lmsvcrt" with
"-lmsvcr71". Its filename is lib/mingw32/3.4.2/specs . After that, use the
--compiler=mingw32 option on build_ext when using distutils.

--
Robert Kern
(e-mail address removed)

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
R

Robert Kern

Alex said:
Jocular, but not sarcastic. I have no problems using mingw if that's
what it takes -- the later instructions I saw were those suggesting the
Toolkit instead, so those are the ones I'm trying to follow. What's the
updated URL for the instructions about using mingw instead?
Click to expand...

Oh, that's right, you need an import library for Python24.dll . If you build
numpy first, it will automatically build the import library for you. The
implementation is fairly simple if you would rather bodge a script together. The
driver is the function build_import_library() here:

http://svn.scipy.org/svn/numpy/trunk/numpy/distutils/mingw32ccompiler.py

This uses the following module:

http://svn.scipy.org/svn/numpy/trunk/numpy/distutils/lib2def.py

--
Robert Kern
(e-mail address removed)

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
R

Ron Adam

Alex said:
Try tinyurl http://tinyurl.com/gv8wr please.
Click to expand...


I still get the following with the tinyurl link:

~~~
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.
~~~


Pasting the above tinyurl into firefox results in the following link.

http://www.microsoft.com/downloads/details.aspx?familyid=272BE09D-40BB-4&displaylang=en

Which appears to still be truncated. :-/


I've also tinyurl'd your URL for the 1.1 SDK, to
http://tinyurl.com/5flob .
Click to expand...

This one works.
 
R

Robert Kern

Martin said:
That shouldn't be a problem: that library is included with Python.
Click to expand...

For mingw, too? I.e. a .a not a .lib?

--
Robert Kern
(e-mail address removed)

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
A

Alex Martelli

Ron Adam said:
I still get the following with the tinyurl link:

~~~
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.
~~~


Pasting the above tinyurl into firefox results in the following link.

http://www.microsoft.com/downloads/details.aspx?familyid=272BE09D-40BB-4&d
isplaylang=en

Which appears to still be truncated. :-/
Click to expand...

True, but here's the kicker: using the full URL, which I just dblchecked
from Rushby's original message as being (enclosing in <...>)...:

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

NOW gives me the same error page too. When Rushby suggested it
yesterday I immediately used it, and it allowed me to download the
Toolkit 2003 just fine -- so, I guess Microsoft must have killed that
possibility shortly thereafter (who said they can't move fast?-).

As of now, I don't know any more of a URL that's usable to download
this, therefore:-(


Alex
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

MS VC++ Toolkit 2003 installer (VCToolkitSetup.exe) 1
MS VC++ Toolkit 2003? 4
Step by step: Compiling extensions with MS Visual C++ Toolkit 2003 - msvccompiler-patch.txt (0/1) 8
ReportLab PDF Toolkit v2.4 released 0
Building Python with the free MS Toolkit compiler 0
Compiling extension with Visual C++ Toolkit Compiler - MSVCR80.dll 3
Problem compiling an extension with MS Visual C++ Toolkit 2003 0
Compiling Python 2.4 extensions with free VC++ Toolkit 8

Members online

Total: 33 (members: 1, guests: 32)
Robots: 342

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,061
Latest member
KetonaraKeto

Latest Threads

Top