Suggestion:  Link the CRT statically into Python26.dll/PythonNN.dll 
and compiled .PYD files, at least when using the Microsoft compiler.  

There has been a number of bugs related to the msvcrt.dll, 
msvcr90.dll, etc.  Many of these would go away if the CRT was 
statically linked into PythonNN.dll.  

The advantages of dynamically linking the CRT are not clear.  The 
binaries are decreased a bit in size, but this is countered by having 
to redistribute the CRT DLL.  

Switching to static linking is a little more work than just flipping a 
switch, as you have to compensate for some of the initialization work 
the DLL does, but it is both doable and worth doing.

This can't possibly work. Extension modules that also link with the CRT 
will thus end with a separate copy of the CRT global state, causing 
crashes.

If you do not *want* to change it, that is your prerogative, but it 
*can* definitely work.

It will seem to work for simple scripts, but many extension modules
won't behave properly because:
- some API functions (PyFile_AsFile, many PyRun_*functions,
PyMarshal_*+FromFile) pass FILE* structures, which differ between
instances of the CRT.
- file descriptors, environment variables, locale settings, the errno
variable, are not shared.
- when a thread exits, it would have to free thread-local storage for
each CRT.

Python uses Ansi C, and has to use the same system as the extension
modules it wants to support. Linking statically with the CRT may be a
solution in specific cases, but not for the general python distribution.

> If you do not *want* to change it, that is your prerogative, but it 
> *can* definitely work.

I don't believe it can work; Amaury has already given a number of
reasons. If you still believe otherwise, and want to see something
change, please try coming up with a patch.

Right, I was thinking about rebuilding Python26.dll.  If we do go down 
that path, I will report the results.

Thanks for the feedback.