[Implemented] New environment variable needed

[petermad]

2HolgerK

pluginbasedir=%COMMANDER_PATH%\plugins%PROCESSOR_ARCHITECTURE%
[PackerPlugins]
RedirectSection=%COMMANDER_PATH%\wincmd_Plugins%PROCESSOR_ARCHITECTURE%.ini

That only helps if you only want to use the 64bit version on your amd64 machines and the 32bit version on your x86 machines - not if you want to run 32bit on amd64 machines.

[petermad]

2Sir_SiLvA

i dont get it how someone can waste so much space with

In usercmd.ini and buttonbars I have used %COMMANDER_PATH%\TOTALCMD.EXE in 100's of places

but im surly the only one that doesnt understand that nonesense...

What is it that you don't understand, and why do you think it is nonsense?

[HolgerK]

That only helps if you only want to use the 64bit version on your amd64 machines and the 32bit version on your x86 machines - not if you want to run 32bit on amd64 machines.

No. %PROCESSOR_ARCHITECTURE% depends on the bitness of the process not of the native system installation.

Regards
Holger

[MVV]

Apart from Autorun.wdx wich is a old Plugin that never worked correctly...

It is NOT an old plugin, it is still in developing, and it WORKS correctly. At least for me and a lot of people who can write correct configuration file.

[petermad]

No. %PROCESSOR_ARCHITECTURE% depends on the bitness of the process not of the native system installation.

Aha, I see now that you are right - my mistake

[petermad]

I would like to bump this request again.

After having used the x64 and th x86 version in parallel for a while now, it is really cumbersome to have to maintain 2 versions of my wcmd_dan.ini, usercmd.ini, wincmd.ini and several *.bar files etc. - all files where I use %COMMANDER_PATH%\totalcmd.exe with different parameters.

I could use %PROCESSOR_ARCHITECTURE% for the command fields using cmd.exe or a batch file with an IF statement - but that is not feasible for the Icon field, and in for example the [Associations] section in wincmd.ini either.

So It could be really nice with a %COMMANDER_PROGRAM% environment variable, and I suggest that it includes the entire path to the running TC executable.

[Balderstrom]

I installed the x64 version as well. Recently I couldn't figure out why TwinKey wasn't working in TC7. Only to find out all my shortcuts shortcuts for TC7 (which don't use a .cmd launcher now) are reading the registry settings for TC8 x64.

In another thread MVV claimed that x64 have their own "area" of the registry. If that is true - it's certainly not valid with TC.

Would of been so much cleaner for Ghisler to give TC8 (beta) it's own registry settings akin to Opera (11 stable) and Opera Next (12).

As far as getting a new "Environment Variable" why not just set it yourself?

Code: Select all

REM START_TCx64.cmd
SET TCx64=x64
START "" "%ProgramFiles%\TotalCMD\TotalCMD64.EXE" /i=C:\Path\To\WinCMD.ini

Code: Select all

REM START_TC.cmd
SET TCx64=
START "" "%ProgramFiles(x86)%\TotalCMD\TotalCMD64.EXE" /i=C:\Path\To\WinCMD.ini

Create a shortcut to the two .cmd's, customize them and change their ICON to the respective TC icon.

[MVV]

BTW 64-bit Autorun.wdx is out (1st beta). So it is possible to define COMMANDER_PROGRAM variable now.

Currently the only way to define different paths for different TC versions - to install 32-bit and 64-bit plugin versions into different folders and provide two different Autorun.cfg files that define different COMMANDER_PROGRAM variables:

Code: Select all

; for 32-bit
SetEnv /EV COMMANDER_PROGRAM %COMMANDER_PATH%\TOTALCMD.EXE

Code: Select all

; for 64-bit
SetEnv /EV COMMANDER_PROGRAM %COMMANDER_PATH%\TOTALCMD64.EXE

Future releases of Autorun.wdx will support pseudo-variable AUTORUN_TCARCH to get TC bitness. It will allow to use condition block in Autorun.cfg:

Code: Select all

If %AUTORUN_TCARCH% == 32 Then
	SetEnv /EV COMMANDER_PROGRAM %COMMANDER_PATH%\TOTALCMD.EXE
Else
	SetEnv /EV COMMANDER_PROGRAM %COMMANDER_PATH%\TOTALCMD64.EXE
EndIf

[petermad]

customize them and change their ICON to the respective TC icon.

That is not the icon I am talking about - I am talking about isons I set in the Icon field of for example buttons and em_commands.

In for example a button like this:

Code: Select all

TOTALCMD#BAR#DATA
%COMMANDER_PATH%\TOTALCMD.EXE /S=L
%Z %P%N
%COMMANDER_PATH%\TOTALCMD.EXE,24
Show content (separate instance)

0
-1

I cannot replace the second %COMMANDER_PATH%\TOTALCMD.EXE,24 with a batch file!

And I really don't see why I should have to use all kind of batch files or wdx plugins for something that requires one or two lines of code in TC, and does not inflict TC's performance speed at all!

[Balderstrom]

@Petermad, Sure you can.

You may want to consider this though: MOVE TCx64 to it's own install location, and rename it to "TotalCMD.exe" --- You can still - if you must use the same wincmd location, and you can use "TotalCMD.exe" and "WMCICONS.DLL" in the icon field of a button.

Semi-OT, Pseudo-Rant, extracted suggestion to fix your issue from below (above quote).

Although this issue, (among others) are caused by a few bad decision by Mr.Ghisler:

1. Adding '64' to longstanding default filenames.
2. Requiring x64 plugins to have '64' in their filename.
3. Not giving x64 it's own registry key.

1) Enables users to install two versions of TC into the same folder -- which is completely uneccessary - there is no advantage to this whatsoever.
2) Enables users to install two versions of a plugin into the same folder: again almost completely unnecessary -- the only advantage to this is using the same plugin config.ini. Which shouldn't be necessary, most plugins aren't going to change their settings often enough that the x86 and x64 couldn't use their own config.
3) Causes multiple issues,
A) when you are trying to separate TC 32/64 bit. They will by default start using the same settings folder, unless you use "/i=" to direct TC to a specific wincmd.ini location.
B) Confusion. When pinning a TC shortcut to the Win7 taskbar, if you haven't specified the /i setting, your config's will get munged.

Note: I don't even use "COMMANDER_PATH", as it is an unwieldy string to stick everywhere. As well, prior to this x64 filename fiasco it wasn't even necessary in a Button's Icon Field: both wcmicons.dll and totalcmd.exe do not require a path in a Button's Icon Field.

Code: Select all

TOTALCMD#BAR#DATA
cm_SaveSelection

TotalCMD.exe,23



530

If TC's binary filename hadn't changed, the above would still work without change.

The clean approach would of:

• Left filenames unchanged; including plugins.
• Checked the "bitness" of a plugin for loading compatibility.
• And added a single key to the wincmd.ini: PluginsBaseDir64=%APPDATA%\GHISLER\plugins64
• Used relative paths (to the pluginbasedir) for plugin locations. Saved the relative path when adding/changing plugins. As is absolute paths are used, which makes the existing PluginsBaseDir ini setting pretty much useless.

As well, I really doubt that anyone changes plugin-settings so frequently that the disadvantages caused by installing two versions of a plugin into a single folder will outweigh any slight convenience.

Now if we want to handle the case of x64 and x86, we might use a single environment variable that is predefined in batch file.
e.g. %TCmd% ---> C:\Program Files (x86)\TotalCMD\TotalCMD.exe
WCMICONS.DLL hasn't changed name.

When pointing out the flaw and problems caused by a single registry key for TC, it should be taken into consideration instead of ignored as if it doesn't matter. It makes absolutely no sense that this wasn't done:

Code: Select all

Ghisler\Total Commander\IniFileName=C:\Path\to\x86\wincmd.ini
Ghisler\Total Commander\InstallDir=C:\Program Files (x86)\TotalCMD
Ghisler\Total Commander x64\IniFileName=C:\Path\to\x64\wincmd.ini
Ghisler\Total Commander x64\InstallDir=C:\Program Files\TotalCMD

I don't understand how can anyone that uses TC, whom most likely organizes their own files meticulously, can think it remotely plausible to put two different installs of a program into the same folder.

Nor can I understand why you are so reluctant to implement a 2 line batch file -- Although maybe it has to do with pinning such a shortcut to the win7 taskbar. You may want to consider this though: MOVE TCx64 to it's own install location, and rename it to "TotalCMD.exe" --- You can still - if you must use the same wincmd location, and you can use "TotalCMD.exe" and "WMCICONS.DLL" in the icon field of a button.

As it stands, these decisions early on in TC x64's life doesn't bode well for the future. I've installed lots of x64 software, and none of them have x64 in their filenames, and none of them recommend installing into the x86 path of program files either.

[Sir_SiLvA]

Although this issue, (among others) are caused by a few bad decision by Mr.Ghisler:

1. Adding '64' to longstanding default filenames.
2. Requiring x64 plugins to have '64' in their filename.
3. Not giving x64 it's own registry key.

I personally find these decisions perfect (Registry shouldnt be used anyway at all but thats just me...)

1) Enables users to install two versions of TC into the same folder -- which is completely uneccessary - there is no advantage to this whatsoever.

Complete and utter bullshit
It makes a system good and sorted having both versions in the same location.
And saying it hasnt any advantages only means you dont use any plugins that are only avail at 32Bit...

Code: Select all

TOTALCMD#BAR#DATA
cm_SaveSelection

TotalCMD.exe,23



530

If TC's binary filename hadn't changed, the above would still work without change.

Seriously? how many times you use TC icons in the Buttonbar?

When pointing out the flaw and problems caused by a single registry key for TC, it should be taken into consideration instead of ignored as if it doesn't matter. It makes absolutely no sense that this wasn't done:

Code: Select all

Ghisler\Total Commander\IniFileName=C:\Path\to\x86\wincmd.ini
Ghisler\Total Commander\InstallDir=C:\Program Files (x86)\TotalCMD
Ghisler\Total Commander x64\IniFileName=C:\Path\to\x64\wincmd.ini
Ghisler\Total Commander x64\InstallDir=C:\Program Files\TotalCMD

Sorry a perfect TC would be with NONE Registry KEy at all...

I don't understand how can anyone that uses TC, whom most likely organizes their own files meticulously, can think it remotely plausible to put two different installs of a program into the same folder.

Thats where you are wrong - its not different programms - its completly the same just one in 32Bit and one in 64Bit
so I dont see why anyone WOULDNT wanna use the same folder...
for example 32Bit & 64Bit have the same helpfile DONT Installing them in the same folder would mean wasting space...

As it stands, these decisions early on in TC x64's life doesn't bode well for the future. I've installed lots of x64 software, and none of them have x64 in their filenames, and none of them recommend installing into the x86 path of program files either.

And I bet none of them is
a) a filemanager
b) less functional than the 32Bit counterpart (plugins)

[petermad]

2Balderstrom
Thanks for the long post - although there wasn't anything in it that I wasn't already aware of.

I actually do have my 64bit and 32bit installations in two different folders - it is not really about that. So I could just rename totalcmd64.exe to totalcmd.exe - and remember to do that for evry update!.

But as you might have noticed I am providing a somewhat popular extended menu system, and I cannot count on the users to have done the same, or that they haven't installed both versions of TC into same directory.

You are right that I don't need %COMMANDER_PATH% in the Icon field for an icon source in TC program folder - but the example I gave was using an icon from totalcmd.exe (not wcmicons.dll) - and that has to be changed to totalcmd64.exe if that file is not renamed - and that is where I cannot use a batch file to make the distinction.

Yes, I could set my own environment variable if I started TC from a batch file - but again I cannot rely that "my users" does the same.

It is all about making it unambiguous and distributable without too many if's (if the user has installed in separate two dirs or not, if he has renamed totalcme64.exe or not, if he is using an autostart of TC - batch or otherwise or not etc.)

I thank you for your workarounds - but they are still workarounds that is cumbersome to distribute to others, and to have to maintain in the long run.

TC has always been very good at being backward compatible, but this new naming approach has suddenly made a lot of my user commands obsolete. A %COMMANDER_PROGRAM% could help a lot making those user commands universal for both versions of TC in the future.

And like with so many other feature requests - it is optional whether you want to use such an environment variable or not, and as long as it doesn't have any unwanted side effects, I don't see any reason to be against it.

[Balderstrom]

Wow. Sir_Silva being rude and belligerent what a shock.

Although this issue, (among others) are caused by a few bad decision by Mr.Ghisler:

1. Adding '64' to longstanding default filenames.
2. Requiring x64 plugins to have '64' in their filename.
3. Not giving x64 it's own registry key.

I personally find these decisions perfect (Registry shouldnt be used anyway at all but thats just me...)

1) Enables users to install two versions of TC into the same folder -- which is completely uneccessary - there is no advantage to this whatsoever.

Complete and utter bullshit
It makes a system good and sorted having both versions in the same location.
And saying it hasnt any advantages only means you dont use any plugins that are only avail at 32Bit...

Well perhaps you are unaware, that TC doesn't need to be installed into the exact same location for it to use the same "location" for it's config files. So no it doesn't make sense to install two versions of TC into the same place.

Code: Select all

TOTALCMD#BAR#DATA
cm_SaveSelection

TotalCMD.exe,23



530

If TC's binary filename hadn't changed, the above would still work without change.

Seriously? how many times you use TC icons in the Buttonbar?

Not that often, but I was actually trying to help, and provide a solution to a problem PeterMad is having as opposed to just attempting poorly to tear someone else apart for their opinion.

When pointing out the flaw and problems caused by a single registry key for TC, it should be taken into consideration instead of ignored as if it doesn't matter. It makes absolutely no sense that this wasn't done:

Code: Select all

Ghisler\Total Commander\IniFileName=C:\Path\to\x86\wincmd.ini
Ghisler\Total Commander\InstallDir=C:\Program Files (x86)\TotalCMD
Ghisler\Total Commander x64\IniFileName=C:\Path\to\x64\wincmd.ini
Ghisler\Total Commander x64\InstallDir=C:\Program Files\TotalCMD

Sorry a perfect TC would be with NONE Registry KEy at all...

According to you. Then it must be true for everyone. A perfect TC would never change. Not use Registry keys and not know where it's config files are. Oh wait, you must want it to work like it did 20 years ago when the program and data and everything was in the exact same location. Ah much better of course.

I don't understand how can anyone that uses TC, whom most likely organizes their own files meticulously, can think it remotely plausible to put two different installs of a program into the same folder.

Thats where you are wrong - its not different programms - its completly the same just one in 32Bit and one in 64Bit
so I dont see why anyone WOULDNT wanna use the same folder...
for example 32Bit & 64Bit have the same helpfile DONT Installing them in the same folder would mean wasting space...

Oh my god. You mean there would be 500-1000KBytes of wasted space by having them installed into a separate folder. Heaven Forbid we can't have that. By All means.

As it stands, these decisions early on in TC x64's life doesn't bode well for the future. I've installed lots of x64 software, and none of them have x64 in their filenames, and none of them recommend installing into the x86 path of program files either.

And I bet none of them is
a) a filemanager
b) less functional than the 32Bit counterpart (plugins)

Yes, I've never tried any other file manager except TC and

A43
AB Commander
AC Browser Plus
AccelMan
Altap Salamander
Cubic Explorer
DOpus
Double Commander
EF Commander
Explorer++
Far Manager
FileBoss
FileMatrix
Frigate
FMEdit
Free Commander
Free Commander XE
Handy File Tools
MeeSoft Commander
MU Commander
Nexus File
RisingWare FileManager
Speed Commander
Tablacus Explorer
Universal Explorer
Unreal Commander
WDE / Windows Double Explorer
wxCommander
XPlorer2
XYPlorer

And possibly a few others I don't recall and have deleted from my archives.

Few filemanagers are less functional than TC. Although they do tend to be missing a few key features (SubDir branch view, and configurable custom columns) - many have features that TC requires plugins for. Many of the alternate premium FileManagers are more customizable than TC: Multiple ToolBars in more than one location at the users discretion. Built-in scripting: At least 1/4 of the ones I listed have this. Speed Commander is possibly the most customizable, you can change fonts and colors for almost every single interface element.
There is a learning curve to most of the tools in question, but almost all of them have Menus that actually are helpful and show off the programs strengths, as opposed to TC's file menus that show an insignificant amount of the commands that are actually available, and use a structure that hasn't been "standard" in over 20 years.

[Balderstrom]

@PeterMad, I'm not against a new Environment variable by default. I'm kinda against the fact that it is necessary: caused by the new naming structure of tc's files. Which I don't believe is advantageous enough to warrant that particular change.

If Mr.Ghisler would rename the binary back to its original "TotalCMD.exe", then all we would lose is the ability to install TC x86 and x64 in the same place. They can still use the same data folder. And various problems would be fixed.

Another thing you could do, as a workaround - extract TC's icons from the binary, and distribute it with your Menus. Then you have a consistent location to reference.

Either way, we will either need a new EnvVar or a fix to TC's binary name. Definitely.

[Stance]

x64
You install in the "normal" "Program Files" directory, which is the x64.
There is the normal program(x64) together with the old (x86), if you like.
When you have both versions in one directory installed, it must be the x64 directory for programs.
When Windows(x64) recognizes a parallel installation of x64 and x86, it demands to use the x64 version (even on a USB stick).
Normally the x64 will start the x86 automatically, when necessary.

Let's say it is downward combatibility:
%COMMANDER_PATH% has to become standard for x64,
and the x64 version can turn it automatically into: %COMMANDER_PATH_X86%
whenever it is necessary (for older x86 TC-Plugins).

Those who uses the 32bit version of TC, don't have to deal with the x64 Variable.
For x86 version the "%COMMANDER_PATH%" is still current.

If you want to use the Total Commander entirely in Windows64, you will just do an update to x64 - and install in parallel, if necessary.

This whole stuff is standard for years...