MS VC++ Toolkit 2003, where?

[Andrew Trevorrow]

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

Ditto for me. And like Ron, the URL (tiny or long) to the 1.1 SDK
*does* work.

This is really frustrating. I've tried different browsers (Safari and IE
on my Mac, IE on WinXP). I've tried emptying the browser cache.

I'm in Australia, so maybe it depends on where the request is coming from?
Any clues on this would be much appreciated.

Or maybe someone is willing to make their VCToolkitSetup.exe available
temporarily...

Andrew

 

[Alex Martelli]

Can you post the complete benchmark results from both systems on the
Macbook? My understanding is that virtualization overhead is not a

OK, I've placed on http://www.aleax.it/Python/ the files that pybench
writes (with the -file option) for each machines, the names are
onmbp.txt and onwin2k.txt -- just 20k each (I'm not sure their format is
documented, but I guess that, worst case, one just needs to study
pybench's sources).

builder knew about, etc. I think Apple switched to the Intel compiler for
x86 macs, was python built with that or with gcc?

The compiler Apple distributes freely is still gcc -- the intel compiler
(rumored to have better optimization) costs hundreds of dollars, so
Apple couldn't possibly distribute it for free with XCode.

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

Consider me available if you need some other tests and don't have other
easy access to OSX and Windows running on the same HW.


Alex

 

[Alex Martelli]

Ditto for me. And like Ron, the URL (tiny or long) to the 1.1 SDK
*does* work.

This is really frustrating. I've tried different browsers (Safari and IE
on my Mac, IE on WinXP). I've tried emptying the browser cache.

I'm in Australia, so maybe it depends on where the request is coming from?
Any clues on this would be much appreciated.

Nope: it's stopped working for me, too.

Or maybe someone is willing to make their VCToolkitSetup.exe available
temporarily...

I suggest any such offers be made privately, since I'm pretty sure
they'd be illegal (at least in the US, dunno 'bout Oz law).


Alex

 

[Andrew Trevorrow]

I suggest any such offers be made privately, since I'm pretty sure
they'd be illegal (at least in the US, dunno 'bout Oz law).

Oh, absolutely -- private offers only please. If it helps ease the
conscience af any prospective benefactors, I *did* have a copy of
VCToolkitSetup.exe at one point. I downloaded it about a year ago
and installed it on Win2000 under Virtual PC, but later trashed
it without making a backup, so that'll teach me.

Failing any offers of help, I guess my options are:

- Wait for Parallels to allow importing VPC disk images (I asked
them about this but it's not going to happen soon).

- Extract all the VC++ 2003 stuff from my VPC Win2000 system and
copy it over to my Parallels system. Sounds like fun...

- Look on ebay for a cheap copy of Visual Studio with VC++ 2003.

- Download VC++ 2005 Express. I'm not planning to build extensions
so I guess I don't really have to use VC++ 2003.

Andrew

 

[Guest]

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

Right.

Martin

 

[Robert Kern]

Right.

Woohoo!

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

 

[Ron Adam]

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

Yes, I tried the full url also, but was hoping I did something wrong.
Sigh... guess not.

<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:-(

And with a new version of windows due at the end of this year, it's
likely those who upgrade to Vista, will also need to upgrade to visual
studio 2005 or later.

I've seen this pattern before. :-/

Ron

 

[Fredrik Lundh]

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

last time I tinkered with mingw, it could link directly against the DLL
file. see the last two minutes in "mingw from scratch in 20 minutes"
post:

http://article.gmane.org/gmane.comp.python.general/388046

the MinGW FAQ says that you can use reimp in cases like this:

http://www.mingw.org/mingwfaq.shtml#faq-msvcdll

but that didn't seem to be necessary (I assume reimp or something
is now integrated in mingw, or maybe I have a magic computer...)

however, note that the FAQ entry says that you can use an existing
LIB file as well, so Python's standard import library should work.

</F>

 

[Edward Elliott]

OK, I've placed on http://www.aleax.it/Python/ the files that pybench
writes (with the -file option) for each machines, the names are
onmbp.txt and onwin2k.txt -- just 20k each (I'm not sure their format is
documented, but I guess that, worst case, one just needs to study
pybench's sources).

Nice, thank you. The files just contain pickled data, but you need pybench
installed to unpickle the classes. I used the command
pybench -s win2k.txt -c osx.txt
to compare the data sets. Here are the results. Left two columns are
Windows times, right column is change from OS X time. I resorted the tests
by percentage change (win2k slowest->fastest) to provide a better picture
of what's going on:

PYBENCH 1.0
Benchmark: /home/ed/python-w2k.txt (rounds=10, warp=20)
measured against: /home/ed/python-osx.txt (rounds=10, warp=20)
Tests: per run per oper. diff
------------------------------------------------------------------------
(slower on win2k)
StringMappings: 309.33 ms 2.46 us +112.53%
ConcatUnicode: 157.47 ms 1.05 us +77.43%
ConcatStrings: 103.57 ms 0.69 us +44.86%
DictWithFloatKeys: 169.10 ms 0.28 us +21.52%
UnicodeProperties: 86.00 ms 0.43 us +6.69%
PythonFunctionCalls: 85.83 ms 0.52 us +1.22%
UnicodeSlicing: 85.64 ms 0.49 us +0.16%
(faster on win2k)
IfThenElse: 70.38 ms 0.10 us -2.45%
SmallLists: 76.98 ms 0.30 us -4.44%
CompareUnicode: 85.22 ms 0.23 us -4.72%
StringPredicates: 87.25 ms 0.31 us -6.13%
NestedForLoops: 38.47 ms 0.11 us -8.07%
CompareInternedStrings: 59.12 ms 0.12 us -8.12%
SimpleListManipulation: 41.93 ms 0.16 us -8.55%
CreateStringsWithConcat: 35.02 ms 0.18 us -9.16%
TryRaiseExcept: 49.62 ms 3.31 us -9.53%
StringSlicing: 63.61 ms 0.36 us -9.77%
SmallTuples: 68.65 ms 0.29 us -12.77%
CompareFloatsIntegers: 72.31 ms 0.16 us -13.72%
Recursion: 45.88 ms 3.67 us -16.20%
CompareFloats: 51.26 ms 0.11 us -17.05%
CompareStrings: 76.14 ms 0.15 us -17.51%
PythonMethodCalls: 60.74 ms 0.81 us -17.75%
CreateUnicodeWithConcat: 90.22 ms 0.45 us -17.76%
BuiltinFunctionCalls: 39.38 ms 0.31 us -17.79%
SimpleFloatArithmetic: 57.72 ms 0.10 us -19.44%
SecondImport: 29.59 ms 1.18 us -19.71%
CreateInstances: 63.02 ms 1.50 us -21.08%
SimpleIntFloatArithmetic: 55.92 ms 0.08 us -21.78%
SimpleComplexArithmetic: 42.40 ms 0.19 us -22.84%
BuiltinMethodLookup: 78.26 ms 0.15 us -24.54%
UnicodePredicates: 56.17 ms 0.25 us -24.75%
SpecialInstanceAttribute: 117.49 ms 0.20 us -24.97%
DictWithStringKeys: 62.30 ms 0.10 us -26.18%
TupleSlicing: 73.63 ms 0.70 us -26.34%
NormalInstanceAttribute: 65.19 ms 0.11 us -26.50%
UnicodeMappings: 65.20 ms 3.62 us -27.68%
SecondPackageImport: 31.25 ms 1.25 us -28.74%
SpecialClassAttribute: 65.94 ms 0.11 us -30.30%
ListSlicing: 50.75 ms 14.50 us -31.37%
SecondSubmoduleImport: 39.39 ms 1.58 us -31.98%
SimpleDictManipulation: 37.88 ms 0.13 us -32.24%
NormalClassAttribute: 66.37 ms 0.11 us -33.40%
DictCreation: 36.66 ms 0.24 us -34.25%
DictWithIntegerKeys: 54.73 ms 0.09 us -35.76%
SimpleLongArithmetic: 27.03 ms 0.16 us -39.80%
TryExcept: 62.54 ms 0.04 us -42.17%
SimpleIntegerArithmetic: 42.88 ms 0.06 us -42.52%
CompareIntegers: 42.81 ms 0.05 us -45.54%
ForLoops: 25.72 ms 2.57 us -53.99%
CompareLongs: 25.45 ms 0.06 us -63.04%
------------------------------------------------------------------------
Average round time: 3847.99 ms -12.61%


None of these tests look to me like anything virtualization would affect.
Beyond that, I'm not sure what to make of it. The fastest gains on win2k
(>39%) seem to come from branching and arithmetic tests. Maybe the ms
compiler has significantly better branch prediction (might explain why
ForLoops and TryExcept have such large gains while NestedForLoops and
TryRaiseExcept are more modest). I can't postulate why some tests show

20% gains, like the *Slicing and *InstanceAttributes ones. No idea why

the first group of tests came out faster on OS X.

I really don't have enough platform-specific knowledge to make sense of
what's going on. Maybe someone with more experience can comment? There
may just be too many factors at play to tease out causal relationships.

The compiler Apple distributes freely is still gcc -- the intel compiler
(rumored to have better optimization) costs hundreds of dollars, so
Apple couldn't possibly distribute it for free with XCode.

I know ICC is commercial and thus not in XCode, but I thought maybe Apple
was using ICC internally to compile some parts of OSX. I have no firm
basis for that belief, it's probably just a rumor I picked up somewhere.

Consider me available if you need some other tests and don't have other
easy access to OSX and Windows running on the same HW.

Thanks.

 

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

however, note that the FAQ entry says that you can use an existing
LIB file as well, so Python's standard import library should work.

Right. MingW (GNU ld) was (apparently) changed to support that shortly
after I started including libpython24.a files with the Windows
distributions.

Regards,
Martin

 

[Ross Ridge]

Right. MingW (GNU ld) was (apparently) changed to support that shortly
after I started including libpython24.a files with the Windows
distributions.

A bug in binutils support for short import library records was fixed
about year ago. You need to use MinGW binutils 2.16.91 or newer if you
want to link with any of the ".lib" files included with Python 2.4.

Ross Ridge

 

[Brian Elmegaard]

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

It is possible to load a .dll in mingw.

 

[sturlamolden]

I believe MinGW can link .lib C libraries files from Visual Studio. But
there are no .a for Python24.dll as far as I can tell.

 

[sturlamolden]

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.

You can find msvcr71.dll in the same directory as Python.

The problem is that you cannot redistribute msvcr71.dll unless you by a
copy of Visual Studio 2003 or install VC++ Toolkit 2003. As far as I
can tell, the .NET SDK license does not give you permission to
redistribute msvcr71.dll. So if you are going to use Py2Exe, this is a
dead end. But if you are just going to build a Python extension, you
don't need to redistribute the DLL (it's already in Python). In that
case you can use MinGW insted. Just make sure MinGW links with the
correct CRT. That is, open

c:\mingw\lib\gcc\mingw32\3.4.2\specs

in an editor and change "-lmsvcrt" to "-lmsvcr71"

There is a second advantage with this. MinGW is an optimizing compiler.
The C/C++ compiler you get from the .NET SDK is not. There is a "Visual
C++ 2005 Express" edition which has an optimizing compiler. But it
links yet another version of the CRT, msvcr80.dll, and does not give
you permission to redistribute msvcr71.dll.

 

[Brian Elmegaard]

I believe MinGW can link .lib C libraries files from Visual Studio. But
there are no .a for Python24.dll as far as I can tell.

But afaik you don't need one.

 

[=?ISO-8859-1?Q?Gerhard_H=E4ring?=]

But afaik you don't need one.

Actually, a libpython24.a file was added in Python 2.4.1. The original
2.4.0 release didn't include one.

AFAIR recent MINGW releases don't need this file any longer:
http://mail.python.org/pipermail/python-dev/2005-October/057693.html

-- Gerhard

 

[Chris Mellon]

You can find msvcr71.dll in the same directory as Python.

The problem is that you cannot redistribute msvcr71.dll unless you by a
copy of Visual Studio 2003 or install VC++ Toolkit 2003. As far as I
can tell, the .NET SDK license does not give you permission to
redistribute msvcr71.dll. So if you are going to use Py2Exe, this is a
dead end. But if you are just going to build a Python extension, you
don't need to redistribute the DLL (it's already in Python). In that
case you can use MinGW insted. Just make sure MinGW links with the
correct CRT. That is, open

c:\mingw\lib\gcc\mingw32\3.4.2\specs

in an editor and change "-lmsvcrt" to "-lmsvcr71"

There is a second advantage with this. MinGW is an optimizing compiler.
The C/C++ compiler you get from the .NET SDK is not.

This is untrue - the MSVC compiler in the VS 2003 Toolkit is exactly
the same compiler that ships with real visual studio, and does
excellent optimization. Modulo all the extremely correct comments in
this thread about how useless it is to make comments about the
optimization capabilities of a compiler, I find that the VS 2003
compiler generally generates faster and (often much) smaller code than
GCC/mingw

There is a "Visual
C++ 2005 Express" edition which has an optimizing compiler. But it
links yet another version of the CRT, msvcr80.dll, and does not give
you permission to redistribute msvcr71.dll.

There are numerous distribution issues with the VS 2005 runtimes (I
don't want to get into them now) besides the legal ones, but it's
useless for building extension modules unless you also re-build Python
(and then your Python can't use any other extension modules). It's
workable for people embedding Python and probably not anyone else.