2.5.1 version of distutils was able to correctly build wininst dists from linux. Right now there are errors which I'll describe in more details once I can get some Linux box.

At least is was reported that compiled binaries contains wrong platform name, i.e. 'linux' and there are errors about inability to look up some compiler options in windows registry while building.

Where was that reported?

In this SCons thread http://scons.tigris.org/ds/viewMessage.do?dsForumId=1268&dsMessageId=2617686

$ python setup.py build bdist_wininst
running build
running build_py
running bdist_wininst
installing to build/bdist.linux-i686/wininst
running install_lib
creating build/bdist.linux-i686/wininst
creating build/bdist.linux-i686/wininst/PURELIB
copying build/lib.linux-i686-2.6/wget.py -> build/bdist.linux-i686/wininst/PURELIB
running install_egg_info
Writing build/bdist.linux-i686/wininst/PURELIB/wget-0.6.egg-info
creating '/tmp/tmpQQZI5O.zip' and adding '.' to it
adding 'PURELIB/wget-0.6.egg-info'
adding 'PURELIB/wget.py'
creating dist
Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules _winreg, win32api or win32con are installed.
removing 'build/bdist.linux-i686/wininst' (and everything under it)
$ ls dist
wget-0.6.linux-i686.exe

The error comes from the msvccompiler module, which shouldn’t get used on non-Windows platforms unless I’m mistaken. Reading the module, I’m not sure at all this command was meant to be run on not-Windows OSes.

It did run ok on non-Windows OSes with previous Python versions.

It certainly should be possible to build these installers, and if I understand your output correctly, an installer *was* built.  The warning is, after all, just a warning, and probably just the warning got added compared to 2.5, but the behavior is the same.

The platform name is a regression though.

The regression is two-fold:

1. platform name regression is caused by r62197 by Mark Hammond - Issue #2513: enable 64bit cross compilation on windows

2. when wininst stub selection started to depend on MSVC compiler version is yet to be investigated, but I am sure that wininst stub selection should only be affected by compatibility with operating system only

More complete research notes are at  https://wave.google.com/wave/waveref/googlewave.com/w+GnQ9tjc8A

http://codereview.appspot.com/1774043

Did you test that patch? ISTM that it contains a syntax error:

+        if not self.distribution.has_ext_modules()
+            and not self.distribution.has_c_libraries():

reuploaded correct version to rietveld.

With the caveat that I haven't tested it (I'm currently traveling), the patch looks good to me.

Raising priority.

I get an error trying to run the command because of the use of the mbcs codec.

Ezio made some comments on Rietveld, I addressed them in a local clone.

Question for Windows users/experts: Do the terms “binary extension” and “binary code” make sense?  If not, I can change them to the clearer “extension modules” and “C code”.

Fixed Ezio comments at http://codereview.appspot.com/1774043

Eric, if I understand you correctly, the mbcs issue you're experiencing is unrelated to the patch. What else do you need?

Is this issue really critical? 
Bump.

I opened another bug for the MBCS problem which prevents me from testing Anatoly’s patch.

2.6 already produces a .linux-i686.exe package instead of .win32.exe when running bdist_wininst. I've now used python2.5 for producing a binary windows installer for roundup.

2.6 only gets security fixes.