Cannot modify TC7 installation package

[Flint]

It was reported on the Russian forum. I'm not sure if this is a bug, but I could not find any mention of this change in history.txt.

When I try to modify the TC7 installation archive (for example to modify install.inf for automatic installation) I get an error message:

---------------------------
Error creating ZIP!
---------------------------
ZIP file contains errors or has unknown format, cannot change!
---------------------------
OK
---------------------------

WinRAR and TC 6.55a can modify it without any problem. Is it intentional? I suspect that it is caused by the digital signature of the installation, but TC6.55a (and earlier versions) can modify the package (with removing the signature, of course).

If this is intentional, I request for a wincmd.ini key that would allow to modify the digitally signed archives.

[petermad]

Confirmed!

[ghisler(Author)]

This happens because the EXE is signed (including the ZIP part). Changing the archive would break the signature, therefore it's not supported by TC.

[Flint]

This happens because the EXE is signed (including the ZIP part). Changing the archive would break the signature, therefore it's not supported by TC.

But TC6.55 supported it. And how in this case can users create the "silent install" TC distributives? This is usually intended for private use only, so why prohibit breaking the signature? Moreover, it is still possible to change the archive from e.g. WinRAR, but why force users to use third-party tools while TC can do the task in the most convenient way?

Please, Christian, if you still want to keep most TC users from accident breaking the signature, add a new wincmd.ini key turned off by default, that will allow to restore the previous behaviour.

[ghisler(Author)]

Signing an EXE patches the EXE headers with the offsets of the signature. You cannot use it unsigned any more.

[wanderer]

And how in this case can users create the "silent install" TC distributives?

Perhaps as i had asked in the past (last message in this thread), it would help to move Install.inf (or parts of it) outside the installation exe and pass its location as a parameter.

[Flint]

Signing an EXE patches the EXE headers with the offsets of the signature. You cannot use it unsigned any more.

Maybe we're talking about different things. What I did:
1. Extract install.inf from the tcmd7pb2.exe.
2. Edited it (changed name to beta 3 ).
3. Opened with WinRAR the archive tcmd7pb2.exe and added there the updated install.inf.
4. Adding was performed and I got a working (though unsigned) distribution file tcmd7pb2.exe. It can be unpacked (I tested it), it can be used for the installation (I tested it too). So, why cannot TC 7 do the same what WinRAR does? Moreover, why cannot TC 7 do the same what TC 6.55 does? I still cannot see any reason for breaking this functionality.

[wanderer]

Maybe we're talking about different things.

Slightly. I'm not asking to "inject" install.inf into tcmd7pb2.exe after modifying it. I'm saying it might be better to have a default install.inf file outside of tcmd7pb2.exe and when tcmd7pb2.exe is executed, if it finds install.inf in the current dir (or perhaps in a path defined by a new registry setting), use the options from it instead of using it from the install.inf included in tcmd7pb2.exe.

[Flint]

Maybe we're talking about different things.

Slightly.

My post was directed to Christian. I understood what you suggested, but I see no reason to abandon the built-in possibility of doing the same what earlier TC versions could do. Your suggestion may be implemented as an additional option, I'm not against it (though I see no real advantages in it...)

[wanderer]

I'm not against it (though I see no real advantages in it...)

It helps with this:

And how in this case can users create the "silent install" TC distributives?

I'm against modifying the installation file every time a new version of TC is released. Install.inf contains options that shouldn't be modified (i.e.

Code: Select all

[Installation]
program=Total Commander 6.55

That means that when a new version is released, you cannot have an install.inf somewhere and just inject it into the installation file. You have to extract it, modify it in order to contain the values you want and then re-inject it. My way, you can have it anywhere you wish, remove (once) any options that shouldn't be modified (like the one i describe above) and just run the installation exe. Everything else will be done automatically. TC will just read the options from this file and any options that do not exist will be read from the file inside the installation exe.

[Flint]

wanderer
Your variant needs keeping two files together. Besides, your variant has one of the disadvantages:
a) if the installer detects the separate install.inf in its folder, then I cannot keep for example a demo-variant of install.inf in this folder which I don't want to be used when I install TC.
b) if the installer takes the path to install.inf as a command-line argument, then I will not be able to use silent install of TC by simple double-clicking its EXE file, I will need to open CMD.EXE, or Start->Run and browse to the folder where TC is located...

The variant with injecting install.inf is free from both these problems. It is already present. It has been present for long time already. So, why remove it now? And why are you against it? Because you don't need it? Well, I don't need UC2 and LHA archivers support, so, let's remove them from TC?

Again: I don't think your variant is bad. I think that both variants may be useful for some users. But one of them has already been present and for some reason was now removed. For TC to be better, it should at least be returned back (Christian, you always thought about compatibility!). And only then further improvements may be implemented.

[wanderer]

wanderer
Your variant needs keeping two files together.

Nope. Just one. An install.inf somewhere. The location will either be:

a. defined in installation command line and then stored (using a switch) in registry so it won't be necessary to define it in every installation.

b. taken from registry.

c. in the same dir as the TC installation file.

The installer will normally use the internal install.inf unless you want to override some values so you will place them in the external install.inf (only them). You never alter the internal file.

That's it.

Besides, your variant has one of the disadvantages:
a) if the installer detects the separate install.inf in its folder, then I cannot keep for example a demo-variant of install.inf in this folder which I don't want to be used when I install TC.

Well, keep it somewhere else then! Not sure i get your point here...

b) if the installer takes the path to install.inf as a command-line argument, then I will not be able to use silent install of TC by simple double-clicking its EXE file, I will need to open CMD.EXE, or Start->Run and browse to the folder where TC is located...

True, you would have to use the command line at least the first time in order to store the location of the external install.inf file.

The variant with injecting install.inf is free from both these problems. It is already present. It has been present for long time already. So, why remove it now? And why are you against it? Because you don't need it? Well, I don't need UC2 and LHA archivers support, so, let's remove them from TC?

Wow, don't shoot the pianist! I'm not against your solution. It's a way that has its advantages as you so well described and after all, it's how it's done for many years. I'm just saying that if Christian decides to keep the current "signature" way of doing things (there are some reasons for that), what i'm proposing could be an alternative.

Christian, you always thought about compatibility!

Yeah, right. Tell him that! He's always doing things having the "compatibility" thing in mind and now he just throws it away?

[Shalimar]

I'd have to agree.. with the change in v7 the next logical method would be for the installer to check for the existence of an alternate install.inf in the same dir or accept such via command line interface.

As it sits now the former method is effectively broken after all.. and coding in these new tweaks should be child's play.