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

[Richard Hanson]

Over the last few days, I reinstalled Win2kSP2 to a spare harddrive I
had just swapped into my Fujitsu LifeBook P1120 (long story <wink>).
Subsequently, I DL'ed the newest Python alpha (2.4a2), and when trying
to install it, I immediately got this error:

This installation package cannot be installed by the
Windows Installer service. You must install a
Windows service pack that contains a newer version
of the Windows Installer service.

(Python 2.4a2 had been working on the LifeBook P1120 before the crash
and subsequent reinstall.)

I immediately tried installing Python 2.4a2 on my older, HP laptop,
and that went fine.

I then went back to the Python alpha page and DL'ed the ~1.8MB file
linked from MS's site. After running the new DL from MS, the Python
MSI installer seemed to run.

However, now Idle wouldn't run, although the Python command line
(console) worked. I tried running Idle using Windows Explorer from
inside my Python installation at:

E:\Python24\Lib\idlelib\idle.pyw (and idle.py)

but those didn't work, either. (E:\ is my Win2k partition and it's a
FAT32 partition.)

I then checked the new 2.4a2 install on the older HP laptop, and there
Idle worked -- from the menu shortcuts, and from launching the
idle.pyw file in Windows Explorer.

(I note that the HP laptop already had Python23 on it. The HP has
*almost* the same OS: Win2kSP3 -- not a fresh install -- and is using
NTFS for its Win2k partition.)

I also note that the *.pyc files were not created by the installer on
the Fujitsu LifeBook P1120 but were on the HP Omnibook 900B (as may be
surmised).

Back on the P1120, I used the MSI installer to "repair" the broken
install twice, used it again to completely remove Python, rebooted
<wink>, and then use the MSI installer one more time to reinstall.
Still no go.

Am I overlooking something simple...?

Thanks for any help anyone can offer.

(I'll try to followup as this gets solved -- I've reinstalled onto an
old harddrive, so I may crash again... )

I'll-keep-at-it-and-try-DL'ing-2.3.4-tonight'ly y'rs
Richard

 

[drs]

Am I overlooking something simple...?

How about SP3, or even 4?

 

[Richard Hanson]

How about SP3, or even 4?

That's a thought. But, as I alluded to in my somewhat lengthy post,
2.4a2 worked with this OEM Win2kSP2 *before* the installation "died"
last Friday.

I have an SP3 CD, so that's doable; I'm on a slightly flaky dialup, so
DL'ing SP4 would be a bit... uh... uncomfortable.

Also, isn't there the general feeling that Win2kSP2 is about as good
as Windows gets (got)? (Aside from the EULA issues; just on the
technical merits?)

Thanks for the idea, though -- much appreciated. I may well try SP3 if
I remain at an impasse.

PS to original post: Further testing shows that the Python command
line (console) is broken, too. Some things sorta work (e.g., "import
sys"); most don't (e.g., "import decimal").

Python-withdrawals-are-painfully y'rs,
Richard

 

[Richard Hanson]

Following up:

After a couple of tries this afternoon, I managed to DL Python 2.3.4
and installed it -- Idle ran and seemed to be normal.

(I thought I would do a quick "test" before posting so I did a "from
test import testall" and got pages and pages of output from 2.3.4 --
about 257kB's worth. <wink>)

Anyway, Python 2.4a2 *still* does not install on my Fujitsu LifeBook
P1120 with Win2kSP2 -- as described in my original post.

So, still stumped.

hard-to-count-the-ways-without-Decimal'ly y'rs,
Richard

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

This installation package cannot be installed by the
Windows Installer service. You must install a
Windows service pack that contains a newer version
of the Windows Installer service.

The problem is what this message says: you need a newer
version of Windows installer.

> Also, isn't there the general feeling that Win2kSP2 is about as good
> as Windows gets (got)?

W2k itself is fine. However, W2k ships with Installer 1.1, W2kSP2
updates that to Installer 1.11, W2kSP3 to Installer 2.0. The Python
MSI file requires Installer 2.0.

http://www.python.org/2.4/

says

# [...] double-click python-2.4a2.msi to find out if your machine
# supports MSI. If it doesn't, you'll need to install Microsoft
# Installer first. Many other packages (such as Word and Office) also
# include MSI, so you may already have it on your system. If not, you
# can download it freely from Microsoft for Windows 95, 98 and Me and
# for Windows NT 4.0 and 2000

You can find the download links on that page.

If it used to work before the reinstallation, you either had a different
service pack installed before, or some other software you had installed
did a silent installation of a new installer release (such as Office
2k).

Regards,
Martin

 

[Richard Hanson]

Martin,

Thanks for replying.

Still no go with the 2.4a2 install on my Fujitsu LifeBook P1120 with
Win2kSP2.

(I have much to learn in writing concise posts, alas -- I appreciate
your patience.)

Minding my own relative ignorance -- and your expertise -- with the
MSI Installer, this morning I redownloaded the MSI Installer
(filename: InstMsiW.exe, filesize: 1,822,848 bytes, version:
2.0.2600.2) from MS using the link on the Python 2.4 page as you
suggest (and as I'd already done yesterday as noted in my original,
somewhat dense post).

Today, I get the same file from MS as yesterday.

Just in case, though, I ran the new download from MS yet again, and it
said:

"Error: The specified service already exists."

If it used to work before the reinstallation, you either had a different
service pack installed before, or some other software you had installed
did a silent installation of a new installer release (such as Office
2k).

I'm at a loss, still. Surely, something I had previously installed in
my own prior installation silently installed something needed for the
Python 2.4a2 install *other than the MSI Installer 2.0* and is
currently missing from my reinstall...?

I'll keep working on it and will report back as a solution develops.

Thanks again, Martin -- much appreciate your and all the other
developer's selfless contributions.

I'm going to try to redownload the Python install file (mine is
filesize: 10,691,072 bytes) even though it "seems" fine -- as I'm
running out of ideas.

Meanwhile, I *do* have Python 2.3.4 to play... er... *work* with (but
I sorely miss Decimal <wink>).

Best regards,
Richard

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

(I have much to learn in writing concise posts, alas -- I appreciate
your patience.)

That is indeed the problem. I stopped reading after the first paragraph.
I'm still uncertain whether you are talking about the original problem
(failure to install the Python msi file), or about the second problem
(MSI file installs fine, but IDLE fails to work) in this message.

I'm at a loss, still. Surely, something I had previously installed in
my own prior installation silently installed something needed for the
Python 2.4a2 install *other than the MSI Installer 2.0* and is
currently missing from my reinstall...?

Why do you think so?

I'm going to try to redownload the Python install file (mine is
filesize: 10,691,072 bytes) even though it "seems" fine -- as I'm
running out of ideas.

If the installation completed with the dialog stating it completed
successfully, it probably did complete successfully indeed.
If you still see a problem, it is likely that this problem is
unrelated to the installation. However, I lost track as to what
this problem might be, and how you have tried to narrow it down.

Regards,
Martin

 

[Richard Hanson]

Martin,

I had just found a workaround for my immediate problem and was
composing a post. Instead, I'll cut-and-paste as appropriate from that
draft, interleaved herein.

That is indeed the problem. I stopped reading after the first paragraph.
I'm still uncertain whether you are talking about the original problem
(failure to install the Python msi file), or about the second problem
(MSI file installs fine, but IDLE fails to work) in this message.

Sorry. I see now that I provided too much background detail getting to
the story -- and didn't write clearly enough, to boot. (As it were.)

The problem: The "python-2.4a2.msi" file appeared to install, but the
install was broken -- IDLE failed to work, and the console was mostly
broken.

Platform: Dual-booting Win98SE and Win2kSP2 on Fujitsu laptop --
primary OS is Win2k on the E: partition.

[...] Surely, something I had previously installed in
my own prior installation silently installed something needed for the
Python 2.4a2 install *other than the MSI Installer 2.0* and is
currently missing from my reinstall...?

Why do you think so?

Well, I admit I was clutching at straws. And ignorance and frustration
were probably making me too reckless with unwarranted assertions.

Now, however, I have some new data (which has me even more confused):

If I have a directory named "Python23" with *only* the immediate
contents of "Lib" in it (no other files or directories nor any of
Lib's sub-dirs) in a separate Win98 partition, then IDLE doesn't run.
However, if I rename or move that dir inside another dir, then IDLE
runs. I can move that subsetted Python23 dir back and forth between
being hidden inside another dir and being in the root, without
rebooting, and IDLE works or not, depending on the visibility of that
very limited subset of the normal Python23 install directory.

I've searched the registry for "Python23" and don't find any reference
there.

It's probably Just Another Windows Problem <wink>, but by now after
fighting Windows installation problems for days -- my brain is mush.
Further, I know virtually nothing about Python's guts.

Perhaps my testing will help you or others ascertain if there even
*is* a problem in general -- or, if there's just something wrong with
my individual machine.

For now, I will just uninstall Python from my Win98 partition.

My apologies again, Martin, for my less-than-optimum posts. I do
appreciate the busyness of the modern era, and I'm very grateful that
folks like you are so willing to give of your valuable time.

You have indeed helped by eliminating many blind alleys I could have
gone down.

Anyway, thanks much -- again.

Best regards,
Richard

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

If I have a directory named "Python23" with *only* the immediate
contents of "Lib" in it (no other files or directories nor any of
Lib's sub-dirs) in a separate Win98 partition, then IDLE doesn't run.
However, if I rename or move that dir inside another dir, then IDLE
runs. I can move that subsetted Python23 dir back and forth between
being hidden inside another dir and being in the root, without
rebooting, and IDLE works or not, depending on the visibility of that
very limited subset of the normal Python23 install directory.

Could it be that you have an environment variable PYTHONHOME or
PYTHONPATH set?

As for the console being mostly broken: what precisely does that mean?
If you run cmd.exe, and start c:\python24\python.exe, what happens?
What happens if you add a -v option to python.exe?

Regards,
Martin

 

[Dennis Lee Bieber]

If I have a directory named "Python23" with *only* the immediate
contents of "Lib" in it (no other files or directories nor any of
Lib's sub-dirs) in a separate Win98 partition, then IDLE doesn't run.
However, if I rename or move that dir inside another dir, then IDLE
runs. I can move that subsetted Python23 dir back and forth between
being hidden inside another dir and being in the root, without
rebooting, and IDLE works or not, depending on the visibility of that
very limited subset of the normal Python23 install directory.

I've searched the registry for "Python23" and don't find any reference
there.

Check for your search path definition(os.environ["PATH"]). It
sounds like the W98 partition is being found before the full install
directory, and as a result, it fails to locate some files...

--

 

[Richard Hanson]

Thanks to the guidance from Martin and Dennis, I *think* that my
problem is finally at least fully worked around -- meaning Python
2.3.4 on a separate Win98 partition can now coexist with Python 2.4a2
on the Win2k partition. Booting into either OS and the respectively
installed Python's IDLE now works.

But, I had to pull "C:\Python23" out of my Win98's PATH to make it
work. Don't know why that was there -- a fresh install of Python 2.3.4
on my Win98 partition now works (IDLE, anyway) without that entry in
Win98's PATH. And, I don't know why my Win2k or my Python 2.4a2 on
Win2k even cares about my Win98's PATH.

For academic purposes, there may be information below that still
suggests some strangeness (at least to me and my machine) re PATH on
Windows, or re having Python in another OS's PATH variable, or both.

So, if you have the time and are interested, read on:

Could it be that you have an environment variable PYTHONHOME or
PYTHONPATH set?

I checked that yesterday. No PYTHONHOME nor PYTHONPATH set in Win2k's
environment variables.

I checked using Two Of The Many Ways To Do The Same Thing so common
with Windows: by right-clicking on "My Computer" and then selecting
Properties | Advanced | Environment Variables, and by using System
Information.

I found for my PATH variable:

%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\WBEM

However...

Check for your search path definition(os.environ["PATH"]). It
sounds like the W98 partition is being found before the full install
directory, and as a result, it fails to locate some files...

Following Dennis's lead and using Python 2.4a2 (with C:\Python23
hidden) to get the environment, today I got the Win2k PATH with the
Win98 PATH concatenated to it (I subsequently rebooted into Win98 on
C: and confirmed its PATH):


E:\\WINNT\\system32;E:\\WINNT;E:\\WINNT\\system32\\WBEM;C:\\WINLICKS;
C:\\WINLICKS\\COMMAND;C:\\Python23\\;C:\\PROGRA~1\\GRISOFT\\AVG6;
C:\\PROGRA~1\\COMMON~1\\AUTODE~1

("WINLICKS" was what I originally named the Windows dir in the Win98
partition a while ago when I first installed it -- at the time, I may
have been a bit frustrated with Windows. [Or, is being frustrated with
Windows somewhat of a tautology? <wink>])

Also today, I tried getting my Win2k environment using Yet Another Way
-- from a Win2k console by typing in "path" -- and got the same
two-OSes-concatenated, system-variables-expanded version shown
immediately above.

As for the console being mostly broken: what precisely does that mean?
If you run cmd.exe, and start c:\python24\python.exe, what happens?
What happens if you add a -v option to python.exe?

I also tried that, yesterday, after reading a post from Tim Peters to
John J. Lee (thread started with <[email protected]>).

In case it has any academic value, here's the full output (with
C:\Python23 visible in the root of C) from yesterday:

| E:\Python24>python -v
| # installing zipimport hook
| import zipimport # builtin
| # installed zipimport hook
| # C:\Python23\Lib\site.pyc matches C:\Python23\Lib\site.py
| import site # precompiled from C:\Python23\Lib\site.pyc
| # C:\Python23\Lib\os.pyc matches C:\Python23\Lib\os.py
| import os # precompiled from C:\Python23\Lib\os.pyc
| import nt # builtin
| # C:\Python23\Lib\ntpath.pyc matches C:\Python23\Lib\ntpath.py
| import ntpath # precompiled from C:\Python23\Lib\ntpath.pyc
| # C:\Python23\Lib\stat.pyc matches C:\Python23\Lib\stat.py
| import stat # precompiled from C:\Python23\Lib\stat.pyc
| # C:\Python23\Lib\UserDict.pyc matches C:\Python23\Lib\UserDict.py
| import UserDict # precompiled from C:\Python23\Lib\UserDict.pyc
| # C:\Python23\Lib\copy_reg.pyc matches C:\Python23\Lib\copy_reg.py
| import copy_reg # precompiled from C:\Python23\Lib\copy_reg.pyc
| # C:\Python23\Lib\types.pyc matches C:\Python23\Lib\types.py
| import types # precompiled from C:\Python23\Lib\types.pyc
| # C:\Python23\Lib\locale.pyc matches C:\Python23\Lib\locale.py
| import locale # precompiled from C:\Python23\Lib\locale.pyc
| import _locale # builtin
| # C:\Python23\Lib\codecs.pyc matches C:\Python23\Lib\codecs.py
| import codecs # precompiled from C:\Python23\Lib\codecs.pyc
| import _codecs # builtin
| import encodings # directory C:\Python23\Lib\encodings
| # C:\Python23\Lib\encodings\__init__.pyc matches C:\Python23\Lib\encodings\__ini
| t__.py
| import encodings # precompiled from C:\Python23\Lib\encodings\__init__.pyc
| # C:\Python23\Lib\re.pyc matches C:\Python23\Lib\re.py
| import re # precompiled from C:\Python23\Lib\re.pyc
| # C:\Python23\Lib\sre.pyc matches C:\Python23\Lib\sre.py
| import sre # precompiled from C:\Python23\Lib\sre.pyc
| # C:\Python23\Lib\sre_compile.pyc matches C:\Python23\Lib\sre_compile.py
| import sre_compile # precompiled from C:\Python23\Lib\sre_compile.pyc
| import _sre # builtin
| # C:\Python23\Lib\sre_constants.pyc matches C:\Python23\Lib\sre_constants.py
| import sre_constants # precompiled from C:\Python23\Lib\sre_constants.pyc
| 'import site' failed; traceback:
| Traceback (most recent call last):
| File "C:\Python23\Lib\site.py", line 304, in ?
| import locale, codecs
| File "C:\Python23\Lib\codecs.py", line 692, in ?
| strict_errors = lookup_error("strict")
| File "C:\Python23\Lib\encodings\__init__.py", line 30, in ?
| import codecs, exceptions, re
| File "C:\Python23\Lib\re.py", line 5, in ?
| from sre import *
| File "C:\Python23\Lib\sre.py", line 97, in ?
| import sre_compile
| File "C:\Python23\Lib\sre_compile.py", line 17, in ?
| assert _sre.MAGIC == MAGIC, "SRE module mismatch"
| AssertionError: SRE module mismatch
| # C:\Python23\Lib\warnings.pyc matches C:\Python23\Lib\warnings.py
| import warnings # precompiled from C:\Python23\Lib\warnings.pyc
| # C:\Python23\Lib\re.pyc matches C:\Python23\Lib\re.py
| import re # precompiled from C:\Python23\Lib\re.pyc
| # C:\Python23\Lib\sre.pyc matches C:\Python23\Lib\sre.py
| import sre # precompiled from C:\Python23\Lib\sre.pyc
| # C:\Python23\Lib\sre_compile.pyc matches C:\Python23\Lib\sre_compile.py
| import sre_compile # precompiled from C:\Python23\Lib\sre_compile.pyc
| Python 2.4a2 (#55, Aug 5 2004, 11:42:43) [MSC v.1310 32 bit (Intel)] on win32
| Type "help", "copyright", "credits" or "license" for more information.

All those references to "C:\Python23" were what originally led me to
focus on the Python 2.3 install in the Win98 partition.

---

So, while 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), I'm quite happy that I can
now get back to using Python rather than trying to get my laptop
"assembled."

In any event, a big hearty thanks once again -- very nice, helpful
folks here!

what's-a-good-Linux-distro-for-a-laptop-with-touchscreen-'ly y'rs,
Richard

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

For academic purposes, there may be information below that still
suggests some strangeness (at least to me and my machine) re PATH on
Windows, or re having Python in another OS's PATH variable, or both.

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

So, while 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), I'm quite happy that I can
now get back to using Python rather than trying to get my laptop
"assembled."

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.

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

Regards,
Martin

 

[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:]

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

[...] 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

 

[David Bolen]

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)

You'd probably need to conditionalize the use of the current directory
on Windows, since on *nix, the current directory isn't automatically
searched. Maybe the current implementation represents a bit of *nix
heritage.

-- David