Start menu items are not being created

English support forum

Moderators: white, Hacker, petermad, Stefan2

Shalimar
Junior Member
Junior Member
Posts: 8
Joined: 2007-11-20, 22:43 UTC

Post by *Shalimar »

ghisler(Author) wrote:There is currently no switch to create icons for ALL users, so the icon will be installed for the currently logged on user. You have to rebuild the installer with modified inf file for that, as described in our Wiki:
http://www.ghisler.ch/wiki/index.php/How_to_make_installation_fully_automatic%3F
Hi again Christian.. as I posted above I already tried that and it failed as well and in other ways. clipped this section (only part w/mods at all) from the custom inf file:

auto=1
hidden=0
lang=1
alllang=0
iniloc=
iniall=1
mkgroup=1
mkdesktop=1
update=1

Tests were tried using straight install w/no switches and also tried with the same /A1D1G1M0K1 added including a variant calling the installer from a batch file in turn called from the w7 installer script. All results in regards to the desktop and start menu icons remained the same (aka not created)

I have a few other ideas though I'll try and report back soon.
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48077
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

You need to change the UserName line:

// User for shortcut creation: Blank for current user, * for all users, or give user name
UserName=

If you leave it blank, TC will try to create shortcuts for "system" user if your installer runs under "system". Try setting
UserName=*
Author of Total Commander
https://www.ghisler.com
Shalimar
Junior Member
Junior Member
Posts: 8
Joined: 2007-11-20, 22:43 UTC

Post by *Shalimar »

ghisler(Author) wrote:You need to change the UserName line:

// User for shortcut creation: Blank for current user, * for all users, or give user name
UserName=

If you leave it blank, TC will try to create shortcuts for "system" user if your installer runs under "system". Try setting
UserName=*
Indeed I noticed that.. and will do a test on it soon.

However that really does not solve the problem for many users that don't want to have to rebuild a custom installer every time you release an updated version. The fix of course being with a revision to the switches to do the same for the shortcuts and/or the ability to just place a customized ini in the same dir as the installer to auto override the default settings. Both ways eing ideal of course since it gives more options for the end user.

For the moment though I just did a dirty old skrool trick.. and made tc_fix.bat too run once the users desktop is created:

c:\totalcmd\TCUNIN64.EXE /r
c:\totalcmd\TCUNINST.EXE /r

Poof desktop and start menu items created. Not a high tech fix and sure as hell is not a long term one IMO but it works for now for those that don't want to build a custom installer and for those using the auto install system from M$.

Also note customized ini used to be easier before the change in installer since you could open/edit/replace etc the ini w/o having to rebuild the entire file. But with the change of installer since it no longer supports editing the ini or replacing it w/o rebuilding. Hence why alternate code being added for the options I would say is the best long term fix.
Shalimar
Junior Member
Junior Member
Posts: 8
Joined: 2007-11-20, 22:43 UTC

Post by *Shalimar »

Well I did another custom build for testing.. mod'd both ini files (32 & 64) accordingly with the usual plus the * for user and rebuilt using the appropriate sfx. Sub'd that in for the std installer from you and well results were not what I expected at all.

It thew an error:

"The setup informaton file was not found!
You need to unpack the whole archive before running install.exe!
Installation aborted!
"

Then the same thing repeated in I think German? (I screen capped it if that helps)

The install failed to not only create desktop/start menu items but failed entirely.. it didn't even create the totalcmd dir. So once the rest of the install was done I did a manual run of the mod'd installer.. ran just fine.. made all the shortcuts etc.. but it did fail to copy the key file over despite it being in the same dir.

So def not what I was predicting.. but in the meantime my low tech batch file fix does work for the time being.
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48077
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

You need to pack the archive with compression rate 0. Why? The installer does not contain ZIP unpacking functions, it reads the files from the uncompressed archive directly in place without unpacking.
Author of Total Commander
https://www.ghisler.com
User avatar
Dalai
Power Member
Power Member
Posts: 9387
Joined: 2005-01-28, 22:17 UTC
Location: Meiningen (Südthüringen)

Post by *Dalai »

Shalimar wrote:However that really does not solve the problem for many users that don't want to have to rebuild a custom installer every time you release an updated version.
You can still use the old installer if needed. Every time a new version is released you can edit the install.inf (and optionally recreate the archive). If you need to use the new installer and make it easier for yourself, you might want to give my script a shot that I posted here (the post is in German, the script itself is in English). The script can automate the creation of TC setups, without the need to edit any TC settings (ZIP compression set to 0), copying any files (SFX) or any other annoying stuff.

Regards
Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64

Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
Shalimar
Junior Member
Junior Member
Posts: 8
Joined: 2007-11-20, 22:43 UTC

Post by *Shalimar »

ghisler(Author) wrote:You need to pack the archive with compression rate 0. Why? The installer does not contain ZIP unpacking functions, it reads the files from the uncompressed archive directly in place without unpacking.
I am well aware of that and it was done with 0 compression (aka store).
Shalimar
Junior Member
Junior Member
Posts: 8
Joined: 2007-11-20, 22:43 UTC

Post by *Shalimar »

Dalai wrote:
Shalimar wrote:However that really does not solve the problem for many users that don't want to have to rebuild a custom installer every time you release an updated version.
You can still use the old installer if needed. Every time a new version is released you can edit the install.inf (and optionally recreate the archive). If you need to use the new installer and make it easier for yourself, you might want to give my script a shot that I posted here (the post is in German, the script itself is in English). The script can automate the creation of TC setups, without the need to edit any TC settings (ZIP compression set to 0), copying any files (SFX) or any other annoying stuff.

Regards
Dalai
Hi Dalai

I'm aware of that as well.. however that again really is not the point. which has been brought up by others as well more than once.

Ultimately the addition of a switch and/or auto override by having an ini in the same dir will be the best solution regardless since it gives the most choices and also eliminates most if not all of the added changes needed not only for the ini but also for the package and/or naming of the package as well.

This is particularly good for those situations where it's all to be dedicated unattended installs via scripting. The file name changing with each version is easy enough to adapt for in scripting so no editing is needed for updated versions. Just a straight dump of the new installer into X location and poof all is good that way. However with the current setup system that simply is not possible and the idea of an unattended install is simplicity in the end for the most part. Therefore aiming for a solution that eliminates added work after it is implemented is the best goal IMO

If it was not and I was going through all of the work w/each release of remaking the installer I'd instead just rework it to use 7zip's sfx instead and an semi-auto creation setup... (Added bonus as well of being much smaller end file though size is not that big a deal on this scale usually). But again that is not the end goal since that would be more limited to my particular setups here and would not be as easily adopted by everyone that downloads TC.

A change in the code directly by Christian however to adopt the 2 changes necessary for those options would achieve that and in the end would make tc's implementation / distribution easier for those users beyond the basic manual install. (And also bypass this bug of the current setup not behaving well with one of the most common unattended install methods TC will ever be used with which in turn impacts a large % of those using TC.. which are in my experience more power users and techs than mom/pop users. Though I typically install TC by default on virtually every system I work on and/or build..)

The really unusual part is TC of all the various apps I've worked with and even tested for unattended install is the only one so far to throw these sorts of errors with this unattended method which like I said before is insanely common since it's a M$ system built into winbloze install/setup for many many years now.


Also don't get me wrong.. i appreciate your response and your script offer as well. But ultimately that is not the best end goal/solution in the long run.
Post Reply