Keeping INI files inside the TC directory.

[cue]

I use TC very much when i´m repairing computers. I use TC mainly from a CD, is there any way I can stop TC from making and leaving a INI file in every computer I use and instead using ini files from within the TC program directory?

(Inireloc does not work)

[Clo]

2cue
Hello !
¤ The INI file must be writable, that isn't the case with TC in a CD !
- So, TC makes a writable INI on the HD of each PC, that is normal, IMHO.
- "Inireloc" can't set <wincmd.ini> on a non-writable media.
- The solution should be to use TC from an USB-stick, instead from a CD, with the variable :
%COMMANDER_PATH% as location of the <wincmd.ini> file.

 Kind regards,
Claude
Clo

[Sheepdog]

You can try to use a Batch to open Total Commander. I made an example

Code: Select all

md %temp%\local
xcopy .\ini\.* %temp%\local
call .\totalcmd.exe /I=%temp%\local\wincmd.ini /F=%temp%\local\wcx_ftp.ini
del /f /s /q %temp%\local\
rd %temp%\local

You have to place this batch in the directory with Totalcmd.exe. And you have to adapt the batch that the xcopy command is pointing to the dir your wincmd.ini is located.

This way you make yourself a temporary directory in the systemwide Temp-folder ('%temp%\local).
After that you copy all needed files to that folder (wincmd.ini wcx_ftp.ini deafult.bar and other *bars)
Then you run Total Commander (with the 'call' command you do not close the batch but wait for closing TC)
Then you delete the files in your created folder 'local' and remove this folder.

Perhaps you have to test a bit with your Buttonbar commands - if you use them. Because running from a temporary folder you have to make the paths more flexible. But using %Commander_path% should solve this problem in most cases.

sheepdog

[cue]

Thank you for your very through answer Sheepdog, I owe you a bone

Clo: if this is the case I guess this is now a feature request.

Why is the INI file kept in the Windows directory, I know it was common practice with windows 3.11 and even 95 but now most programs try to keep it clean and keep the settings in the REG or its own program directory (witch I like better).

Please make the program able to stand alone (not spread files) in a non writeable location, if I disable saving any window or settings there should not be anything that the program needs to write...?

[Clo]

2cue
There is always something to write into the INI(s) files !
At least the program-items layout , following the screen-definitions !
- I you repair a PC having i.e. 600x800, then another having 1024x768, TC must add a section [1024x768]…
- It should need to have a <wincmd.ini> with all definitions…
- I don't think that a media where TC can't write be a good way to use it as "mobile"…
 Kind regards,
Claude
Clo

[Sheepdog]

Thank you for your very through answer Sheepdog, I owe you a bone

Let's see if I can earn a piece of meat to the bone.


As you mention it I remember that TC really doesn't need a ini you could write on. If you start the program using the /i= and /f= options it will not create any ini file at all - if the files exist in the location.

So you may start TC with Totalcmd.exe /i=.\ini\wincmd.ini /f=.\ini\wcx_ftp.ini if your ini- files are in the subfolder 'ini' into your program-folder at CD.
This way you couldn't change the settings of course. But if I understand you right, you won't do it anyway.

You could also use Lefteous 'LaunchTC' which always uses the settings in its ini file 'launchTC.ini' . I'm using a beta which is even able to run TC frm CD with the autorun by inserting the CD.

sheepdog

[cue]

outstanding!

Now, if I could only have some fries with that, I would be set for life

[white]

Then you run Total Commander (with the 'call' command you do not close the batch but wait for closing TC)

True if Total Commander is a batch file. If not use "start /w" instead.

[Sheepdog]

True if Total Commander is a batch file. If not use "start /w" instead.

Call works fine, I assure you. I have tested it before. You could use 'start /w ' too, of course.

But 'call' would work even under Windows 3.1, if it comes to that. It's the old fashioned command I have learned while working with DOS.

sheepdog

[Hacker]

It's the old fashioned command I have learned while working with DOS.

Yeah... do you still feel the need to run MEMMAKER once in a while, too?

Roman

[Sheepdog]

Yeah... do you still feel the need to run MEMMAKER once in a while, too?

Of course I never used to use memmaker. I looked always with mem for available space and optimized my config.sys by hand
But right. sometimes I have the strange feeling that optimizing config.sys would improve the speed of XP. But it never does

sheepog

[Hacker]

optimized my config.sys by hand

So did I... Ahh, those were the times of multiconfigs, "/ram /noems"'s, "switches=/f"'s, DEVICEHIGHs and LHs...

Roman

[Sheepdog]

Then you run Total Commander (with the 'call' command you do not close the batch but wait for closing TC)

True if Total Commander is a batch file. If not use "start /w" instead.

So after all I have to correct myself. The 'call' command works fine for XP Pro.
But for Win95/win98 it does not. There you have to use indeed 'start /w' because - as white pointed out to me - the call command does not stop the executing of the batch. So the temporary wincmd.ini would be deleted before TC is closed.

With Windows 3.1 this batch could not work because you could not have called a windows programm from command line. For a DOS Program it would have worked in all Operating systems since DOS 3.0 (perhaps DOS 2.0 )

So I'm again stumbled into a M$-trap when they discontinued the behavior of their commands..

Thanx to white for giving me the crucial hint.


sheepdog

[white]

For a DOS Program it would have worked in all Operating systems since DOS 3.0 (perhaps DOS 2.0 )

For a DOS program the "call" command was not necessary.

[Sheepdog]

For a DOS Program it would have worked in all Operating systems since DOS 3.0 (perhaps DOS 2.0 )

For a DOS program the "call" command was not necessary.

Without using the 'call' you would not return to the batch after running the DOS-program. So I think you are wrong in this case.

sheepdog