odd experience updating tcmd 13

[drrob1]

On a different winxp sp3 box than I've described here before, I have tcmd 9-13 installed. I consider this box my main xp box. I have tcmd 12.11 and 13 open. I ran update from tcmd 13, and as soon as it starts to download an update, I closed the main tcmd 13 and left the update process run. I have been doing this for many version updates since v 9.

After the update ran, it said that there were components that it needed to update that it could not. It was referring to the running session of tcmd 12.11. Why would upgrading v 13 trigger an error because of v 12.11 being open?

I have already described v13 clobbering a v12.11 upon installing v 13 to a thumbdrive. There seems to be some kind of interaction btwn installing v 13 and an already installed v12.11. Maybe some sharing of files? I don't know, but the install program for v13 is causing errors/messages to be generated from v 12.11.

I am posting this because I believe there is a bug in the install routine for v13; I have never seen this behavior before involving v9-12. Each subsequent version installation really had no effect on earlier versions.

This installation issue is new for v 13.

 

[Steve Fabian]

From: drrob1
| On a different winxp sp3 box than I've described here before, I have
| tcmd 9-13 installed. I consider this box my main xp box. I have tcmd
| 12.11 and 13 open. I ran update from tcmd 13, and as soon as it
| starts to download an update, I closed the main tcmd 13 and left the
| update process run. I have been doing this for many version updates
| since v 9.
|
| After the update ran, it said that there were components that it
| needed to update that it could not. It was referring to the running
| session of tcmd 12.11. Why would upgrading v 13 trigger an error
| because of v 12.11 being open?
|
| I have already described v13 clobbering a v12.11 upon installing v 13
| to a thumbdrive. There seems to be some kind of interaction btwn
| installing v 13 and an already installed v12.11. Maybe some sharing
| of files? I don't know, but the install program for v13 is causing
| errors/messages to be generated from v 12.11.
|
| I am posting this because I believe there is a bug in the install
| routine for v13; I have never seen this behavior before involving
| v9-12. Each subsequent version installation really had no effect on
| earlier versions.
|
| This installation issue is new for v 13.

FYI: I have raised an issue recently which has the same underlying issue: V12 and V13 use some DLLs that are identical (but different from all previous versions). If you explicitly download the V13 installer, and try to run it when V12 is already running, it indicates that it cannot complete installation without system restart. I complained that V12 and V13 are in different directories, so updating V13's copy of the DLLs does not interfere with V12's running. Rex replied to the effect that this is a restriction enforced by the MS installer, take any complaints to Redmond.
--
Steve

 

[drrob1]

> From: drrob1
> | On a different winxp sp3 box than I've described here before, I have
> | tcmd 9-13 installed. I consider this box my main xp box. I have tcmd
> | 12.11 and 13 open. I ran update from tcmd 13, and as soon as it
> | starts to download an update, I closed the main tcmd 13 and left the
> | update process run. I have been doing this for many version updates
> | since v 9.
> |
> | After the update ran, it said that there were components that it
> | needed to update that it could not. It was referring to the running
> | session of tcmd 12.11. Why would upgrading v 13 trigger an error
> | because of v 12.11 being open?
> |
> | I have already described v13 clobbering a v12.11 upon installing v 13
> | to a thumbdrive. There seems to be some kind of interaction btwn
> | installing v 13 and an already installed v12.11. Maybe some sharing
> | of files? I don't know, but the install program for v13 is causing
> | errors/messages to be generated from v 12.11.
> |
> | I am posting this because I believe there is a bug in the install
> | routine for v13; I have never seen this behavior before involving
> | v9-12. Each subsequent version installation really had no effect on
> | earlier versions.
> |
> | This installation issue is new for v 13.
>
> FYI: I have raised an issue recently which has the same underlying issue: V12 and V13 use some DLLs that are identical (but different from all previous versions). If you explicitly download the V13 installer, and try to run it when V12 is already running, it indicates that it cannot complete installation without system restart. I complained that V12 and V13 are in different directories, so updating V13's copy of the DLLs does not interfere with V12's running. Rex replied to the effect that this is a restriction enforced by the MS installer, take any complaints to Redmond.

Interesting. When I complained that installing v13 damaged by v12.11
installation, Rex did not see the link and thought it was something odd
about my particular computer.

Seems like they are linked after all and it should not be a surprise
that installing v13 can affect v12.11, as it did for me.

That should have been clearer.