* Christian Heimes, on 07.07.2010 22:47:
The main problem that the required MSVC redistributables are not necessarily
present on the end user's system.
It's not a problem for Python anymore. It took a while to sort all
problems out. Martin and other developers have successfully figured out
how to install the CRT for system wide and local user installations. A
system wide installation installs the CRT in the side by side cache
(WinSxS). A local installation keeps the msvcrt90.dll and the
Microsoft.VC90.CRT.manifest next to the python.exe. Python extensions no
longer embed a manifest so they share the CRT from the python.exe process.
In order to ship a standalone exe you have to keep the CRT next to your
exe. This should work for py2exe binaries as well. At our company we
install our application stack entirely from subversion including Python
2.6.5, Sun JRE and lots of other stuff. This works perfectly fine for us
even for servers without the MSVCRT redistributable.
I think you're talking about a different problem. The CRT installed along with
CPython works for extensions using the MSVC 9.0 CRT.
However developing an extension with MSVC 10 the extension will use the 10.0
CRT, which is not necessarily present on the end user's system.
As I see it there are five solutions with different trade-offs:
A Already having Visual Studio 2008 (MSVC 9.0), or coughing up the
money for an MSDN subscription, or visiting trade shows, so as to
obtain that compiler version.
-> Not an option for everybody.
B Linking the CRT statically.
-> Increased size, problems with CRT state such as file descriptors.
C Linking the CRT dynamically and bundling the MSVC redistributables
with the extension.
-> Even more increased size for the download, but smaller total
footprint for extensions in sum; same CRT state problems.
D Linking the CRT dynamically and providing an optional download and
install of the redistributables if they're not present. This would
best be done with some support from the Python installation machinery.
-> Small nice size for extensions, still same CRT state problems.
E As D + a new compiler-independent native code interface that
does not carry dependencies on CRT state such as file descriptors, like JNI.
-> Really huge effort, and cannot be applied until some new Python version.
And I think the clue here is that the CRT state problems can be avoided by
careful coding.
Hence, for those who cannot do A I think B is a realistic practical option, and
D would be nice...
Cheers,
- Alf
--
blog at <url: http://alfps.wordpress.com>
--
http://mail.python.org/mailman/listinfo/python-list
