homepage

bdist_wininst installers created by py3k fail due to PySys_SetArgv and
Py_SetProgramName both being passed 'char *' strings instead of wide
strings.
The patch is against the svn trunk as currently Python 2.x and 3.x share
the same bdist_wininst stub. The patch doesn't change the behaviour on
Python 2.x, and continues to allow the same executable stub to be
shared, as the appropriate signature is determined at runtime based on
the Python version.
The patch does not include the 2 new stub executables required
(wininst-9.0.exe and wininst-9.0-amd64.exe), but the patch *and* the new
stub executables should be merged into whatever py3k branches are
appropriate. I've tested (pywin32) installers based on the new stub on
python 2.6 32bit, and python 3.0 32 and 64bit.

Is it really useful to be have the same stub for 2.x and 3.x? I think it
would be better if they mutually ignore each other, and be different.

> Is it really useful to be have the same stub for 2.x and 3.x? 
> I think it would be better if they mutually ignore each 
> other, and be different.
Good question! I'm not really aware of the complexities involved in
merging between the various branches, but given the fairly trivial
nature of the patch I figured there were potential advantages in both
identical source and stubs. I'm happy to work the patch into either
#ifdef based (ie, identical source, different stubs), or "unconditional"
(both source and stubs different) if you prefer - and if so, which of
those 2 do you prefer?
On a related note, its obviously true that the same final installer will
not be able to be shared between 2.x and 3.x, as is currently possible
between pure-python installers between the 2.x series. However, this
could be addressed in .py code at a later time while still allowing the
same stub to be shared if that is desirable.

> Good question! I'm not really aware of the complexities involved in
> merging between the various branches, but given the fairly trivial
> nature of the patch I figured there were potential advantages in both
> identical source and stubs. I'm happy to work the patch into either
> #ifdef based (ie, identical source, different stubs), or "unconditional"
> (both source and stubs different) if you prefer - and if so, which of
> those 2 do you prefer?
It's still possible to merge changes reasonably even if the "target"
(i.e. py3k) differs slightly from the source. Therefore, I think the 3k
version should unconditionally only support python3x.dlls. IOW, let
the sources diverge (for sake of simplicity of each individual source).

Attaching an updated patch against the py3k branch which makes no
attempt to work on py2k.

This patch is fine, please apply.
I wish it wouldn't be necessary to widen char*, but start off with
wchar_t from the beginning. AFAICT, this would work fine for argv[1]
(there are only two arguments, anyway), but might get complicated for
argv[0].

Checked into py3k as r6998; merged to release30-maint as 69099. I hope
I got that right!

> Checked into py3k as r6998; merged to release30-maint as 69099. I hope
> I got that right!
If you ask whether checking into py3k was the right thing: yes, it was.