Ever since Python 2.4.0, the Python for Windows binaries have been build with MSVC7, as opposed to version 6. The main reason for this, IIRC, was that VC6 was no longer available to buy, and was increasingly difficult to get hold of. (See the bottom of the python-dev Summary for 2003-05-01 through 2003-05-15 for more.) Microsoft sweetened the deal by giving free copies of VC7 to several key Python developers, and pointing out that free (as in beer) versions of the compilers are available for download.
All C coded Python extensions distributed as Windows binaries need to be compiled by the same version of VC as core Python, so this required all extension builders to get VC7. But then, most probably already had it, and given that VC6 was no longer available at all, this probably made things better rather than worse on the whole. It was the right decision.
Update: Phillip J. Eby correctly points out that an extension builder doesn't need VC7 - only the core developers need that. An extension builder can use the free Microsoft compiler, GCC, or MinGW.
On the other hand, being Microsoft, there was bound to be a price to pay - and it turns out to be a big one. Software compiled with VC7 requires a dll, msvcr71.dll, at runtime. Owners of a full version of VC7 are free to distribute this, but no one else is.
This isn't a problem for the standard Python distribution, since the core Python developers have donated copies of VC7. It's not a problem for Python C extension builders and users, either, because the extensions can be compiled using the free compiler, and use the version of msvcr71.dll distributed with the standard Python distribution at runtime.
So, why is msvcr71.dll a problem? Py2exe, that's why. It's no longer possible to use py2exe to build a working stand-alone executable from a Python script and distribute it to people who don't have Python already installed. The exe built by py2exe needs msvcr71.dll to run, and you can't legally distribute that unless you own VC7.
Was this a deliberate trap? Probably not. I'm not that paranoid about The Great Satan, err, I mean Microsoft. I doubt anyone realised in advance that there'd be a problem. But it does underline the need to avoid proprietary software in general, and Microsoft software in particular, if any reminder were needed.
In fact, there's at least one other problem that I've come across caused by the move to VC7. There are Python bindings available for Subversion, (which rocks, by the way) and you need these to run Trac. But the Python Subversions bindings aren't available for Python version 2.4, and won't be in the foreseeable future; Apache is still compiled using VC6, so Subversion is built using it too.
I don't really have much in the way of a suggestion as to a solution to this, I'm afraid. It would, of course, be lovely if Python for Windows was built with a free compiler such as GCC or MinGW, but there would be a huge amount of effort involved in making the move, for which I'm in no position to volunteer.
Posted to Python by Simon Brunning at August 12, 2005 03:34 PMGCC?
I like that you didn't turn your post into an anti-Redmond rant, sir, but simple is better.
These .dll complexities are about enough to make one tired.
"""so this required all extension builders to get VC7"""
Not true; MinGW/GCC works just fine for extension building with 2.4.
As for py2exe, doesn't py2exe distribute the Python DLL, which is the thing that needs msvcr71.dll?
"MinGW/GCC works just fine for extension building with 2.4."
True. I'll post an update.
"As for py2exe, doesn't py2exe distribute the Python DLL, which is the thing that needs msvcr71.dll?"
py2exe doesn't distribute anything. It builds a directory containing a bunch of files for *you* to distribute. That directory does contain python24.dll, but doesn't contain msvcr71.dll. So, you can distribute it, but it won't work. (It'll work on your PC, 'cos you have msvcr71.dll elsewhere. But if you distribute the files to someone else who doesn't already have msvcr71.dll, it won't fly.)
If you drop msvcr71.dll in the directory, it will work anywhere - but you can't legally distribute it.
Posted by: Simon Brunning on August 12, 2005 05:20 PM"Python Subversions bindings aren't available for Python version 2.4"
I run Trac 0.8.4 + Subversion 1.2.1 + Python 2.4.1 without problems.
You don't need any new stuff or new compiler. Install existing Python Subversion bindings, go to libsvn directory, go with your favorite hexeditor over dlls (_wc.dll, _client.dll, _core.dll,
_delta.dll, _fs.dll, _ra.dll, _repos.dll) and change references to python23.dll to python24.dll (change one symbol per file). Now you can run Trac.
When you distribute a py2exe'ed app arren't you distributing Python and by extension allowed to distribute the msvc71.dll?
This is not one of the things that Microsoft is out to screw anyone with. They want people to use their tool. You need msvc71.dll to use the products of that tool. Therefore they are anot going to complain that you are distributing a requirement for using their tool.
Besides which if you download the free toolkit you get the redistributable rights to msvc71.dll. If you are concerned download that and install it.
http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&displaylang=en
"When you distribute a py2exe'ed app arren't you distributing Python and by extension allowed to distribute the msvc71.dll?"
Yes.
It's perfectly safe to ignore the "IANAL but here's some FUD I just POOMA" posts to various Python forums. In general, programmers aren't properly configured to understand legal documents.
Posted by: Fredrik on August 13, 2005 05:29 AM(btw, if anyone wants to play AL when reading the MS EULA, make sure you understand what the words "you", "licensee software", "redistributables" and "distributors" mean in that text.)
Posted by: Fredrik on August 13, 2005 05:36 AMSo, have I got this wrong? I'd be delighted to hear it...
Posted by: Simon Brunning on August 15, 2005 09:31 AMAside from the compiler switch, there is the fact that GCC and VC will generate fundamentally different code for various C constructs. I don't know if this is a problem, but it has the potential to impact performance/memory usage/a million other cases that one might not think of, outside of changing the Makefiles around.
In my day job we regularly test using ICC, VC7, and GCC; each compiler has varying pros and cons. ICC in particular, can boost performance hugely for our specific application.
Posted by: David Wilson on August 15, 2005 06:48 PMDoes this mean I only have to buy VC7 and then I am legally authorized to redistribute msvcr71.dll together with the result of py2exe?
Posted by: Alex Greif on August 16, 2005 12:12 PM"Does this mean I only have to buy VC7 and then I am legally authorized to redistribute msvcr71.dll together with the result of py2exe?"
As long as you're using a standard Python build, you don't need to buy VC7 to do that. The python.org team uses a properly licensed VC7 to build Python, which turns Python into "licensee software" and you into a "distributor" doing "further distribution" of Python to end users (with your own stuff added on top, of course). And further distribution is perfectly okay, as long as you only ship the MS components together with proper "licensee software" (=Python), and that all parties respect the relevant portions of the original EULA (this basically means that you cannot use tricks to circumvent the MS EULA, e.g. by attempting to relicense the MS DLL's under less restrictive licenses or "viral" licenses. The same applies to all other licensed components, of course. You cannot relicense the Python core either.).
(If in doubt, consult a real lawyer. If you do, make sure that he/she understands the various levels here -- i.e. that "you" in the MS EULA applies to the Python developers, not yourself).
Posted by: Fredrik on August 16, 2005 02:26 PMmaybe the following solves the problem: I dont pt the dll inmy ow intaller package (InnoSetup exe file) but tell the innoSetup Scipt to download the dllfrom the internet while installing the package. So it would be sort of dependency but not a redistribution.
Posted by: Alex Greif on August 16, 2005 03:54 PMWell, according to Fredrik, there isn't a problem, and he's seldom wrong.
Posted by: Simon Brunning on August 16, 2005 04:01 PMMaybe a last thought. I suspect Python 2.3 requires msvcrt.dll version 6, I did not verify that; However the msvcr71.dll is the MS C Runtime dll and Python 2.3 also linked with a C runtime. I believe that this dll however was already in Windows 2000, XP, etc. This is why more than likely the question was not raised before. GCC built python versions also link with a C runtime, i.e. libc6, or glibc I believe.
I would wager that an old version of Windows 95 and a fresh python 2.3 py2exe built app, the app would not run. It just so happens that MS placed the dll in each version of Windows post VS6.
So, where am I going with this. Only trying to say that the dll is fundamental and likely already on most systems due to Windows update, or other apps. Also, I believe Fredrik is correct, but I am no expert, just thought this was an interesting discussion.
By the way it is possible to build a Windows app without the C runtime. Most of the C runtime functions have equivalents in the Win32 API. I would guess the python developers would not want to go this route as it would increase the complexity of the build and be tro specific to Windows, were I would assume most of the code is not platform specific and only what must be specific is isolated.
On a gcc system I have been curious if it is possible to eliminate the C runtime? don't know the answer.
"Hi! I'm from Google. I'm a Googlebot! I will not kill you."
http://www.ftrain.com/robot_exclusion_protocol.html
Posted by: Fredrik on August 19, 2005 11:19 AM(maybe it's just me, but I think my last comment made a little more sense before Simon got rid of the "spam" comment that preceeded it ;-)
Posted by: Fredrik on August 22, 2005 10:28 PM;-)
Posted by: Simon Brunning on August 23, 2005 09:08 AM"... an extension builder doesn't need VC7 - only the core developers need that"
but the second paragraph of
http://www.python.org/doc/2.4.1/ext/win-cookbook.html says
"Notice that you should use the same version of VC++that was used to build Python itself."
Ummm, which one is right?
--bong
Posted by: Bong Munoz on August 23, 2005 10:29 PMmy dll file is missing, how do i download it
Posted by: kjanet cutler on September 8, 2005 03:55 PMimportant
Posted by: vivek on October 26, 2005 03:58 PM