«

[Martin]
> I'd like to encourage feedback on whether the Windows installer works
> for people.

[Me]
> It worked fine for me, upgrading from 2.4 on XPsp2.

Gah! I didn't mean to send that. It *didn't* work, as it turns out. It
didn't overwrite python24.dll. It's possible that there was a process
running at the time that was using python24.dll (I have a bunch of
scheduled jobs that run in the background), but the installer didn't say
anything about being unable to write the file.

I could try again, but maybe there's some useful information you can get
from the partially upgraded environment. Here's how the \python24
directory looks:

C:\Python24>dir /od
Volume in drive C has no label.
Volume Serial Number is E031-65A3

Directory of C:\Python24

26/11/1997 06:14 766 py.ico
11/04/2002 06:40 766 pyc.ico
24/03/2003 22:33 633 python.exe.manifest
24/03/2003 22:33 633 pythonw.exe.manifest
03/11/2004 15:37 13,499 LICENSE.txt
09/11/2004 16:27 61,440 Removepywin32.exe
09/11/2004 16:28 99,601 pywin32-wininst.log
30/11/2004 11:49 1,867,776 python24.dll
21/01/2005 14:21 20,992 Removeelementtree.exe
21/01/2005 14:21 3,191 elementtree-wininst.log
31/01/2005 14:46 61,440 Removectypes.exe
31/01/2005 14:46 25,371 ctypes-wininst.log
15/02/2005 14:30 61,440 Removepy2exe.exe
15/02/2005 14:30 <DIR> Scripts
15/02/2005 14:30 5,621 py2exe-wininst.log
18/02/2005 16:59 50,963 README.txt
10/03/2005 10:13 228,444 NEWS.txt
10/03/2005 10:36 4,608 w9xpopen.exe
10/03/2005 10:46 4,608 python.exe
10/03/2005 10:46 5,120 pythonw.exe
11/03/2005 08:55 <DIR> DLLs
11/03/2005 08:55 <DIR> include
11/03/2005 08:55 <DIR> libs
11/03/2005 08:55 <DIR> tcl
11/03/2005 08:55 <DIR> Tools
11/03/2005 08:55 <DIR> ..
11/03/2005 08:55 <DIR> .
11/03/2005 08:55 <DIR> Doc
11/03/2005 08:56 <DIR> Lib
19 File(s) 2,516,912 bytes
10 Dir(s) 14,520,340,480 bytes free

And here's what Python thinks it is:

C:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>

--
Richie Hindle

Richie Hindle wrote:
> Gah! I didn't mean to send that. It *didn't* work, as it turns out. It
> didn't overwrite python24.dll. It's possible that there was a process
> running at the time that was using python24.dll (I have a bunch of
> scheduled jobs that run in the background), but the installer didn't say
> anything about being unable to write the file.

Ah, ok. I'll see whether I can reproduce this.

Regards,
Martin

Richie Hindle wrote:
> I could try again, but maybe there's some useful information you can get
> from the partially upgraded environment. Here's how the \python24
> directory looks:

I tried to reproduce it, and failed - if the DLL is not in use, it is
updated correctly; if it is in use, a window pops up telling you so, and
it won't let you proceed until you have terminated the process that has
it open.

However, I just noticed that the python24.dll is in c:\python24. Could
it be that you have another one in \windows\system32? If so, could it
also be that the installer has told you that the target directory
exists, and asked whether you want to proceed anyway?

In that case, your 2.4 installation was a per-user installation, and the
2.4.1c1 installation was a per-machine (allusers) installation. These
are mutually not upgradable, so you should now have the option of
uninstalling both in add-and-remove programs.

Regards,
Martin

[Martin]
> However, I just noticed that the python24.dll is in c:\python24. Could
> it be that you have another one in \windows\system32?

I do, yes.

> If so, could it
> also be that the installer has told you that the target directory
> exists, and asked whether you want to proceed anyway?

It probably did, yes.

> In that case, your 2.4 installation was a per-user installation, and the
> 2.4.1c1 installation was a per-machine (allusers) installation. These
> are mutually not upgradable, so you should now have the option of
> uninstalling both in add-and-remove programs.

I'd be surprised if the existing 2.4 was per-user, because I usually ask
for all-users. It's possibly that it was an all-users installation but I
copied the DLL into C:\Python24 for some reason [...digs around...] yes, I
think that must be the case. It has a creation date much later than
C:\python24\Lib, for example.

The python24.dll in C:\windows\system32 is 2.4.1c1. In which case, I
think it all worked perfectly but didn't take into account my manual
addition of python24.dll to C:\python24 - which is fair enough, really.

[ I only see "Python 2.4.1c1" in the Add/Remove list, and no other Python
2.4 entries (apart from the likes of "Python 2.4 ctypes-0.9.2") but
that's to be expected. ]

Thanks for looking into this, and sorry to take up your time with
something that boils down to user error.

--
Richie Hindle

Richie Hindle wrote:
>>If so, could it
>>also be that the installer has told you that the target directory
>>exists, and asked whether you want to proceed anyway?
>
>
> It probably did, yes.

If this was a true upgrade (allusers to allusers), it didn't ask
the question. It only asks if it thinks this is a fresh install,
yet the target directory is there already.

> I'd be surprised if the existing 2.4 was per-user, because I usually ask
> for all-users. It's possibly that it was an all-users installation but I
> copied the DLL into C:\Python24 for some reason [...digs around...] yes, I
> think that must be the case. It has a creation date much later than
> C:\python24\Lib, for example.

Ah, ok. I could not have thought of *that*. That also explains it: the
upgrading simply did not manage to remove/replace your copy of
python24.dll.

It's easy to see the effect, then: Windows looks for python24.dll first
in the directory of python.exe (where no DLL should have been found),
and would only fallback to system32 then (which it didn't in your case).

Regards,
Martin

Richie Hindle wrote:
>>If so, could it
>>also be that the installer has told you that the target directory
>>exists, and asked whether you want to proceed anyway?
>
>
> It probably did, yes.

If this was a true upgrade (allusers to allusers), it didn't ask
the question. It only asks if it thinks this is a fresh install,
yet the target directory is there already.

> I'd be surprised if the existing 2.4 was per-user, because I usually ask
> for all-users. It's possibly that it was an all-users installation but I
> copied the DLL into C:\Python24 for some reason [...digs around...] yes, I
> think that must be the case. It has a creation date much later than
> C:\python24\Lib, for example.

Ah, ok. I could not have thought of *that*. That also explains it: the
upgrading simply did not manage to remove/replace your copy of
python24.dll.

It's easy to see the effect, then: Windows looks for python24.dll first
in the directory of python.exe (where no DLL should have been found),
and would only fallback to system32 then (which it didn't in your case).

Regards,
Martin

[Richie]
> It's possibly that it was an all-users installation but I
> copied the DLL into C:\Python24 for some reason

[Martin]
> Ah, ok. I could not have thought of *that*. That also explains it: the
> upgrading simply did not manage to remove/replace your copy of
> python24.dll.
>
> It's easy to see the effect, then: Windows looks for python24.dll first
> in the directory of python.exe (where no DLL should have been found),
> and would only fallback to system32 then (which it didn't in your case).

Yes, that's what's happened. I've copied the new python24.dll into
C:\python24, and everything now thinks it's 2.4.1c1. Sorry about that.

(I wish I could remember why I'd copied the DLL, but I can't. I'd like to
think there was a good reason.

--
Richie Hindle

Richie Hindle wrote:
> Yes, that's what's happened. I've copied the new python24.dll into
> C:\python24, and everything now thinks it's 2.4.1c1. Sorry about that.

Is there a reason to keep in c:\python24? Just removing it there should
work as well.

Regards,
Martin