After consideration of issue 4120 and issue 4566, it seems to me that
executables created by bdist_wininst will have a manifest referencing
the MSVC9 assembly, and thus will be in a similar position to the .pyd
files in issue 4120 - that unless the assembly is installed globally or
next to the executable itself, the executable will not start.  Note that
I have not verified this, but have verified the final installer
executable references the CRT assembly, and given those other bugs,
expect it to be true.

It seems to me a reasonable solution would be to have the bdist_wininst
stub use a static copy of the C runtime library.  While this means 2
copies of the CRT will eventually be loaded and would otherwise be
considered evil, the way the stub dynamically loads Python and the few
API functions it uses means it might be reasonable in this case.  Would
the trivial patch which achieves this be desired?

I think it would be even better if it didn't link with the CRT at all,
but until somebody provides a patch for that, linking statically sounds
fine to me.

Ironically I just received personal mail:

"""I have downloaded pywin32_212 [2.6] three times today. the download
completes successfully. but on running the pywin installer i repeatedly
get an error."""

Attached is a screen-shot of the error dialog
"pywin32-212-win32-py2.6.exe...has failed to start because the
application configuration is incorrect..."""

My apologies for not being more on top of this, but I couldn't find the
answer in the developer FAQ.  This question applies to issue 4566 and
will partially apply to issue 5076.  The patches are against the trunk -
after checking in, what action should I take to ensure it is merged to
2.6 and 3.x?  I'm happy to manually merge and checkin to those branches
if appropriate; if so, should I check it into branches/release30-maint
as well as branches/py3k?

Thanks

> My apologies for not being more on top of this, but I couldn't find the
> answer in the developer FAQ.  This question applies to issue 4566 and
> will partially apply to issue 5076.  The patches are against the trunk -
> after checking in, what action should I take to ensure it is merged to
> 2.6 and 3.x?  I'm happy to manually merge and checkin to those branches
> if appropriate; if so, should I check it into branches/release30-maint
> as well as branches/py3k?

If you want to backport the changes yourself, you should run
svnmerge.py; not sure how well this works on Windows, though (it invokes
an svn binary). The merge flow would be

  trunk -> release26-maint
       \-> py3k -> release30-maint

It's important to use svnmerge only, so that the merge tracking
properties are right.

In 2.6, do "svnmerge.py merge -r<rev>", then "svn commit -F
svnmerge-<tab>". In 3k, do the same, although you might have
to recompile the stubs in-between in case there are merge
conflicts on the binary files. In 3.0, do the same, but you
need to "svn revert .", because there will be merge conflicts
on ".".

If you don't want to perform all these operations, let me know,
and I'll do them.

Thanks for the merging advice!

The patch to the build system is indeed trivial - unfortunately it also
failed to work correctly due to install.c using freopen, a CRT function,
to redirect the output.  Interestingly, this probably means that if
someone attempted to use python 2.6 to create a pure-python .exe
installer, they would fail to see any output when installed to earlier
Python versions (and vice-versa...)

I've worked up a patch for install.c which uses the win32 API to achieve
the same result using SetStdHandle() etc.  This technique requires the
handles to be redirected before the Python DLL is loaded, so I took the
opportunity to refactor things a little - we now have 2 locations that
perform the redirection instead of 3 but I didn't see huge benefit in
trying to knock that down to 1.

The patch is against the trunk but should also be applied to 2.6 and the
3.x branches.  I've tested the new code-paths using a 32bit trunk build
only but it should work the same everywhere.

Looks fine to me, please apply.

As all the IO is done with Win32 directly, you might as well call
DeleteFile instead of remove (unless I miss something).

Checked into trunk as r69094; merged to release26-maint as r69095, py3k
as r69096 and release30-maint as r69097.