MSI Installer Problem: can't install 2.4a2 on new install of Win2kSP2

[Richard Hanson]

[Dual-booting Python 2.3.4 on Win98, and Python 2.3.4 and 2.4a2 on new
install of Win2k. Initial install of 2.4a2 on Win2k didn't work, but
now is. Strangeness noted. Ongoing discussion:]

Martin v. Löwis wrote:

>I'm not quite sure why you have the Win98 path in W2k, but it may be
>that W2k also executes certain autoexec things.

[FWIW, more testing this morning, unsure of its the relevancy:]

First, I searched the Fujitsu's Win2k (E:) partition for "autoexec"
and only turned up "autoexec.nt" which is the same as the autoexec
file found on my HP laptop's Win2k. Nothing unusual noted there.

Then, I decided to try and "break" Win2k's 2.4a2 again by putting
Python back into the Win98 (C:) partition's PATH -- today, that
*didn't* break Win2k's 2.4a2.

I next cleaned up Win98's PATH of other extraneous entries, but left
the Python entry in Win98's PATH for testing purposes. No change noted
with this step -- Python 2.3.4's IDLE still worked booting into Win98,
and 2.4a2's IDLE still worked booting into Win2k.

Thinking that the problem may only crop up with the initial
installation of 2.4a2 under my dual-booting conditions, I uninstalled
Python 2.4a2 (Win2k's 2.3.4 already being uninstalled) from E:'s
Win2k. I then checked the registry. The registry still had a few
references to Python 2.4 as well as several to Python 2.3 in places
other than MRUs, etc. For example, the Python file associations were
still in the registry, and Python 2.4 appeared in branches labeled
"Shell" and such. The desktop icons to things Python also still
retained their usual Python appearance. Not being familiar enough, I
tried no manual removal of the Python entries from Win2k's registry. I
did try MS's RegClean 4.1a and another registry cleaner, but the
Python entries remained.

Nonetheless, I reinstalled 2.4a2, and again IDLE works with Python 2.3
in the other OS's partition.

(I'm still picking up my Win98's PATH in my Win2k's PATH using "path"
at a cmd.exe console, however...?)

A more complete testing will have to wait till I get a new harddrive
and again reinstall. (I can't *wait*! <wink>) 

>> [...] I don't understand why having a separate OS on a different
>> partition affected 2.4a2 on Win2k as above (remembering that 2.3.4 on
>> Win2k worked fine with that configuration) [...]
>
>That might be a subtle bug. Python tries to find out its own executable
>path name, in order to find the location to the Python installation. It
>considers two alternatives
>a) argv[0] contains a \. If so, python.exe was fully qualified, so we
>    know the path.
>b) if there is no \, python.exe must be on the PATH. So we look there,
>    and find one in C:\python23, and believe this is us. This logic is
>    flawed, as we should *first* look into the current directory (I
>    think)
>
> From then on, everything fails: we load the 2.3 library, which has a
>different sre version. So regular expressions don't work, and that
>causes pretty much everything to break.

Check. I follow up to here -- thanks!

>What surprises me, though, that this algorithm is *only* executed
>if GetModuleFileName fails, which should not happen in your case...

But now I'm way over my depth -- and today's further testing only made
things more murky for me, alas. (If I discover anything else that
seems relevant to me in my ignorance, I'll post -- also, alas. <wink>)

At any rate, thanks, Martin, for taking the time to help edify me a
little about the nuts-and-bolts of Python.

I'm just glad that things are currently working! :-)

Best regards,
Richard

-- 
email works if unmunged:
sick<PERI0D>ole<P0INT>fart<PIE_DEC0_SYNTAX>newsguy<MARK>com