TC seems not to autoclose when instaaling beta version

[ghisler(Author)]

It may be related to the displayed Windows version. What does TC 8.51a show on Server 2008 in menu Commands - System information - Software for the fields:
- Windows version
- Windows mode?

And what does TC 8.52 show?

[ghisler(Author)]

In Total Commander 8.52a RC1, I'm now trying to dynamically load the function even when not on Windows Vista or newer. Please test it! If it still fails, Server 2008 may be missing that function.

[karlchen]

What does TC 8.51a show on Server 2008 in menu Commands - System information - Software for the fields:
- Windows version
- Windows mode?
And what does TC 8.52 show?

Total Commander 8.51a, 32-bit as well as 64-bit, display:
- Windows version: 6.1 (Build 7601)
- Windows mode: Windows Server 2008 R2 SP1

Total Commander 8.52, 32-bit as well as 64-bit, display:
- Windows version: 6.1 (Build 7601)
- Windows mode: Windows Server 2008 R2 SP1

[karlchen]

Upgrade from Total Commander 8.52 32+64-bit to Total Commander 8.52a RC1 32+64-bit

Scenario 1:

Total Commander 8.52 32 bit and Total Commander 8.52 64-bit, both loaded.
From inside Total Commander 8.52 32 bit launched the setup programme tc852ax32_64_rc1.exe.
The setup programme closed Total Commander 8.52 32 bit, but not Total Commander 8.52 64-bit.
The update installation failed.


Scenario 2:

Total Commander 8.52 32 bit and Total Commander 8.52 64-bit, both loaded.
From inside Total Commander 8.52 64 bit launched the setup programme tc852ax32_64_rc1.exe.
The setup programme closed both Total Commander 8.52 32 bit and Total Commander 8.52 64-bit.
The update installation succeeded.


Conclusion:

At least on Windows Server 2008 R2 SP1, I do not see any change in behaviour of the combined installer.
(But hey, the workaround is pretty trivial. And most of the time the T.C. 64-bit will be used, so the symptom would not even show.)

Karl

[ghisler(Author)]

So apparently QueryFullProcessImageName fails when the installer is launched from TC 8.51a, but works when launched from TC 8.52. Doesn't really make any sense.

Btw, are TC 8.51a and 8.52 installed in the same directory when you make these tests?

[karlchen]

Hello, Christian.

There seems to be a consistent misunderstanding. Maybe this is my fault, because I keep on explaining too badly what I do.

Total Commander 8.51a, 8.52 and 8.52a have all been installed in the same programme folder.
T.C. 8.51a has been upgraded in place to 8.52.
T.C. 8.52 has been upgraded in place to 8.52a RC1.

dawie, the thread starter, reported a problem, experienced when he started the combined T.C. installer on Windows 10 64-bit.
As I have got no Windows 10 anywhere, I tried what happened when starting the combined installer on Windows 7 64-bit and Windows Server 2008 R2 SP1 64-bit from inside the running Total Commander 8.5x 32-bit instance.

In order to reproduce the reported problem, I did what I would normally not do:
I first launched 2 instances of the Total Commander version which I was going to upgrade: totalcmd.exe (32-bit) and totalcmd64.exe (64-bit).
From inside totalcmd.exe (32-bit) I launched the combined installer of the target version.
Started from inside totalcmd.exe (32-bit), the combined installer kept on terminating totalcmd.exe (32-bit), but could never terminate totalcmd64.exe (64-bit).

Started from inside totalcmd64.exe (64-bit), however, the same combined installer consistently terminated totalcmd.exe (32-bit) and totalcmd64.exe (64-bit).

This behaviour has been the same for me throughout both upgrades:
+ from T.C. 8.51a to 8.52
+ from T.C. 8.52 to 8.52a RC1

So whatever you have changed inside the installer between the T.C. versions, it does not have any visible effect for me.

Yet,

• as the thread starter reported about Windows 10, not Windows 7 or Server 2008 R2 SP1
• as no-one else reported to see the same behaviour as me in the same environments
• as the problem can be easily worked around: launch the combined installer from inside totalcmd64.exe (64-bit), not from inside totalcmd.exe (32-bit), or close any opened totalcmd64.exe beforehand

I am not sure whether it is worth the time and effort to go on investigating the issue at this point in time. But of course it is up to you to decide.

Cheers,
Karl

[karlchen]

Good night, Christian.

I think I solved my own riddle.

In all my tests I had opened exactly 2 instances of the Total Commander version which I was about to upgrade in exactly this order:
(1) totalcmd.exe (32-bit)
(2) totalcmd64.exe (64-bit)

This means when I launched the combined installer from totalcmd.exe (32-bit), this has always been the first of two running T.C. instances (and failed to close instance #2 64-bit)

Now I reverted this order:
(1) totalcmd64.exe (64-bit)
(2) totalcmd.exe (32-bit)

Now totalcmd.exe (32-bit) was the second of 2 running T.C. instances, when I launched the combined installer from inside totalcmd.exe.
And this time it worked. The combined installer closed both T.C. instances (totalcmd64.exe and totalcmd.exe) and the upgrade installation succeeded.

Next, I did several tests with 3 running Total Commander instances, various combinations of totalcmd.exe and totalcmd64.exe.
+ Total Commander (x32 or x64) 8.51a
+ [2] Total Commander (x32 or x64) 8.51a
+ [3] Total Commander (x32 or x64) 8.51a

The result of these tests seems to be that

• if the combined installer 8.52a RC1 is launched from inside a 32-bit Total Commander instance,
• this instance must be the highest instance, in the given example, [3] Total Commander
• then it will succeed, close all 3 T.C. instances and finish the installation successfully.
• else it will fail to close all 3 T.C. instances and fail.

Result for launching the combined installer 8.52a RC1 from inside a 64-bit Total Commander instance:
If the combined installer is launched from inside a 64-bit Total Commander instance, the position of this instance in the stack of running 32-bit and 64-bit instances is irrelevant.

Karl

[ghisler(Author)]

2karlchen
Thanks for the additional info, I will try that!

[ghisler(Author)]

Since I do not have access to Windows Server 2008 R2, I have tested this on Windows XP, 7, 8.1 and 10, but without any luck.

Here is what I tried:
1. Downloaded TC 8.52 and 8.52aRC1 32-bit+64-bit combined
2. Installed TC 8.52 32-bit+64-bit combined
3. Started totalcmd.exe from the desktop, confirmed 1-2-3 dialog
4. Started totalcmd64.exe from the desktop, confirmed 1-2-3 dialog
5. Switched back to totalcmd.exe
6. Went to Download folder and started 8.52aRC1 installer (32+64bit)
7. It offered to install update -> confirmed, both programs were closed

So either it's some server-specific problem, or closing the 32-bit version took so long that the installer gave up waiting and didn't close the 64-bit app.

[karlchen]

Hello, Christian.

As it works for you, as no-one else has confirmed that he can reproduce the behaviour which I get on Server 2008 R2 SP1 as well as on my Windows 7 HP 64-bit SP1 desktop machine, let us simply assume that these machines are the exception to the rule.

And, no, closing the 32-bit T.C. instance(s) is always immediate, no delay. 1 sec. or less.

Server specific issue on Server 2008 R2 SP1 would not explain why it happens on my Windows 7 HP 64-bit SP1 system, too. I have setup my home machine, but I have not setup the Windows Server 2008 R2 SP1. Only T.C. has been installed and configured on both machines by me.
(Could I be doing something wrong after more than 17 years still? Could it be a plugin? I have never bothered to test with a plain T.C.)

Cheers,
Karl

[karlchen]

Hello, Christian.

That's it! It must be one of my plugins!
I rolled back everything on the Server 2008 R2 SP1.
Re-installed T.C. 8.51.a 32+64-bit combined.
Took away my wincmd.ini and my wcx_ftp.ini.

Launched
(1) totalcmd.exe 32-bit
(2) totalcmd64.exe 64-bit
(3) totalcmd.exe 32-bit

Went back to T.C. instance (1) - 32-bit.
Launched tcmdr852ax32_64_rc1.exe and selected update installation like in all tests before.
The combined installer closed all 3 loaded T.C. instances, 32-bit and 64-bit in no time at all and finished the update sucessfully.

Now the question arises which plugin might to be blamed?
But this is my problem and definitely no show stopper for the release of Total Commander 8.52a.

Cheers,
Karl

[karlchen]

It is getting more complicated for me than I had hoped.

Reverted back the installation to T.C. 8.51a and removed all plugins. But kept my wincmd.ini file.
Launched the combined 8.52a RC1 installer. And the problem was back.
So it must be one or several of the parameters which have been tweaked in the course of the past 17 years that cause the effect.

I doubt I will ever take the time to figure out which of the numerous parameters which are no longer on their default values might be the culprit. Just too much hassle.

Anyway, the root cause is on my side, very likely one or more of all the tweaked wincmd.ini parameters.

===The End===no happy end for me===not to be continued===before Friday===

[ghisler(Author)]

OK, I don't want to delay the release of TC 8.52a any more because of this problem. If you find the reason, let me know, and I will try to fix it for the TC9 installer.

[karlchen]

Hello, Christian.

While updating from Total Commander 8.52a RC1 to Total Commander 8.52a (final), a suspicious setting inside wincmd.ini, section [Configuration], MinimizeOnClose=3, has been identified.

Whenever 1 reset MinimizeOnClose=0 (default value), restarted all Total Commander 8.52a RC1 instances (mix of 32-bit and 64-bit), the mysterious problem was gone.
As soon as MinimizeOnClose=3 was re-enabled, all Total Commander 8.52a RC1 instances (mix of 32-bit and 64-bit) restarted, the mysterious problem returned and made the combined installer fail to close all running T.C. instances.
Reset MinimizeOnClose=0 (default value), restart all Total Commander 8.52a RC1 instances (mix of 32-bit and 64-bit), mysterious problem gone again and combined installer succeeds.

Might make sense because MinimizeOnClose > 0 limits the API calls which can be used to close T.C. Correct?

Cheers,
Karl

[karlchen]

Addendum:

With the default setting MinimizeOnClose=0, the combined Total Commander 8.52a installer, started from inside Total Commander 8.5x 32-bit - plus 2 more Total Commander 8.5x 64-bit instances loaded, all from the installation target folder - works flawlessly even on Ubuntu 64-bit + Wine.
The installer closes all 3 loaded Total Commander instances and updates the installation successfully. Cf. post here.
With MinimizeOnClose=0, even this side issue encountered on Ubuntu 64-bit + Wine will not occur.

Testing environment this time:

Code: Select all

$ inxi -Sx; wine --version
System:    Host: voyager Kernel: 3.2.0-90-generic x86_64 (64 bit, gcc: 4.6.3) Desktop: Gnome Distro: Linux Mint 13 Maya
wine-1.4