Observations on v15 install

[Peter Bratton]

I just installed v15.00.18 on XP. I installed to the same directory as v14, but I had not emptied the directory before the install. I told the installer to replace previous versions. After installing, I typed "help" and got the v14 help page instead of the v15 page. I ran "copy /c/n <source directory> <TCMD directory>" to list the files that would be refreshed, I got a half dozen hits. Then I compared those files:
2006-02-22 17:40 34,304 ___A___________ BorlndMM.dll
2006-02-22 16:40 34,304 ___A___________ BorlndMM.dll

2013-03-11 21:19 297,520 ___A___________ onig.dll
2013-01-20 00:25 297,544 ___A___________ onig.dll

2000-01-24 07:01 453,632 ___A___________ stdvcl40.dll
2000-01-24 06:01 453,632 ___A___________ stdvcl40.dll

2013-03-11 19:50 3,578,592 ___A___________ tcmd.chm
2013-01-20 00:08 3,518,140 ___A___________ tcmd.chm

2013-03-11 21:19 151,688 ___A___________ TPipe.exe
2013-01-20 00:25 136,016 ___A___________ TPipe.exe

2013-03-11 21:19 249,856 ___A___________ WiFiMan.dll
2013-01-20 00:24 249,856 ___A___________ WiFiMan.dll

It looks like the install overlooked onig.dll, tcmd.chm, TPipe.exe and WiFiMan.dll. The other 2 files are identical except for a 1-hour timestamp difference.
--
Peter

 

[Steve Fabian]

Replacing a released version (v14) with an experimental (beta) version (v15) shows a great degree of trust in the perfection of the still experimental version, which comes with a "no guarantees" caveat. Installing a new version in the same directory as an old version is another risky action. The set of files with a new version may not be the same as the old; the remove/keep old version dialog actually refers to different BUILDS of the SAME version.

The 1-hour time difference would probably disappear if you used UTC for both. Most likely you installed one of each pair when standard time was in effect, the other when DST was in effect. The @FILESTAMP function of Charles Dye's ISO8601.dll plugin (which converts the internal UTC timestamp of NTFS based on the time zone in effect at the time of the file event, ignoring the currently effective time time zone) would display them identically, too. For all that are fully identical, my guess is that either they did not change for the new version, or that both copies actually belong to the same version.

 

[Peter Bratton]

Replacing a released version (v14) with an experimental (beta) version (v15) shows a great degree of trust in the perfection of the still experimental version, which comes with a "no guarantees" caveat. Installing a new version in the same directory as an old version is another risky action. The set of files with a new version may not be the same as the old; the remove/keep old version dialog actually refers to different BUILDS of the SAME version.

I've used this product since 1994. While an occasion an upgrade presented a problem, most of the time I have had nothing to worry about. Besides, a public beta already will have passed many alpha hurdles thanks to rigorous testing by people such as yourself. And I'm prepared to backtrack. Like the very first time my computer crashed, I thought it was the end of the world, but now I rebuild my PC from scratch (almost) every year or so.

The 1-hour time difference would probably disappear if you used UTC for both. Most likely you installed one of each pair when standard time was in effect, the other when DST was in effect. The @FILESTAMP function of Charles Dye's ISO8601.dll plugin (which converts the internal UTC timestamp of NTFS based on the time zone in effect at the time of the file event, ignoring the currently effective time time zone) would display them identically, too. For all that are fully identical, my guess is that either they did not change for the new version, or that both copies actually belong to the same version.

You're right, I upgraded to v14.03.59 on Jan. 20, i.e. on standard time, which accounts for the apparent 1-hour difference in the timestamps. But the v15 install should have overwritten the other 4 files. v14 and v15 WiFiMan.dll file sizes are the same but a comparison of the files with FC showed lots of differences.

That was on a home PC. I also installed v15 on 2 workstations, "replace existing versions" and in the same directory but I did not empty those directories beforehand. On one workstation the install replaced everything, on the other it overlooked WiFiMan.dll
--
Peter

 

[Steve Fabian]

Another reason for some DLLs not being replaced with the newer could be that they were in use. Since the installer checks before starting the actual installation that no conflicting program are running, and v14 definitely conflicts with v15, it could happen only by choosing to ignore the conflicts (I doubt any tester would make that choice, so it maybe an untested choice with its outcome not necessarily correct), or possibly by the DLL not being unloaded quickly enough.

Personally I keep parallel directories for all versions from 4nt5, though it's been ages since I actually ran anything prior to v8, and nothing before v11 with any frequency. OTOH I have aliases to access the help files of v5 or any later version from the command prompt of any 4NT or TCC version. I do this to be able to respond to support questions from users of older versions.

 

[rconn]

I just installed v15.00.18 on XP. I installed to the same directory as v14, but I had not emptied the directory before the install. I told the installer to replace previous versions.

The installer does not support overwriting different major versions (and never has). The "replace previous versions" refers to previous builds of the same major version (for example, 14.03.58 to 13.03.59)