Comments about TCmd's configuration files (INIs)

[VadiMGP]

2 jb. Well, so i deleted my answer.

[wanderer]

I don't think backup of registry much more complicatd then backup of tens files.

In my opinion a backup of specific portions of the registiry is much more complicated than a configuration directory (regardless how many .ini files it contains) that is located within the user data. In the latter case the configuration data is automatically backed up whenever the user data is backed up. There is just no extra work!

True but only if all of your ini files are located in one dir. If every ini is located in the program dir or some other dir, you have to create a script to back them up or use a program to do it for you automatically.

Let compare ini files with registry:
1. Ini files limited by size

Wrong.

That's OS dependent but in Win2k and later, practically there is no limit.

4. all above requires much more programmer's effort to provide data integrity.

The goal is to make programs more user-friendly, not more programmer-friendly.

Ok, now i think i got you! Why would a program not using the registry be more user friendly? If you want to make a program really user-friendly, you create simple, clear and well-organized configuration dialogs, you don't ask the user to go and modify the registry or an ini file. Only power users are interested in that, who usually care more in altering the power options of the program than it's friendlyness.

[jb]

The "TEXT" or "L" macro is used to make a hard-coded Unicode string.

Essentially you are right. Meanwhile I checked the definition of TEXT. It is a macro that works only with normal literal strings (const char[]). It uses the C preprocessor "token-pasting" operator ## to join L and the passed argument. But L is not a macro! It is built into C and C++ to be used as prefix for wide literal strings (const wchar_t[]).
Examples:
TEXT("Hello") expands to L"Hello" (legal literal wide string).
TEXT(szVar) expands to LszVar (may be a legal variable name, but is most probably not what is intended).

[Lefteous]

... when you reinstall it, it remembers the path so setting the initial path to "C:\Program Files\TotalCmd" ....

this settings is AFAIK stored in the windows registry. Why not store it in "Common Appdata". The exact location of this directory can be obtained through the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Appdata
Maybe there are also API functions to retrieve this information.

The "TEXT" or "L" macro is used to make a hard-coded Unicode string.

Essentially you are right. Meanwhile I checked the definition of TEXT. It is a macro that works only with normal literal strings (const char[]). It uses the C preprocessor "token-pasting" operator ## to join L and the passed argument. But L is not a macro! It is built into C and C++ to be used as prefix for wide literal strings (const wchar_t[]).
Examples:
TEXT("Hello") expands to L"Hello" (legal literal wide string).
TEXT(szVar) expands to LszVar (may be a legal variable name, but is most probably not what is intended).

You're right. My statement wasn't 100% correct in that point. L is Ansi C(++) and _T or TEXT is provided by the Microsoft compiler.
If you want to build an application that is capable to be compiled as ASCII or as Unicode yo have to use TEXT or _T macro. If you define UNICODE here the hardcoded strings will be expanded to Unicode. If you don't define UNICODE the strings will be expanded to ASCII characters. TEXT is the choice for a generic (_tmain) windows application. _tmain will be expanded to main or wmain in dependendy to UNICODE. You will have to use the generic version of a string function. WritePrivateProfileString instead of WritePrivateProfileStringW or WritePrivateProfileStringA. The advantage is easy to see: One programm for ASCII and unicode.
If you use L you will have to define UNICODE. In this case your hardcoded strings will be expanded to Unicode. If you don't define Unicode here all string functions will not work properly.

[Hacker]

VadiMGP,
What is the reason? I myself use DOS almost everyday (and it seems to be continued for years ), but 16-bit TC? Unbelievable!

Probably Windows 3.x...? Don't know. But Black Dog is using it for instance, too.

HTH
Roman

[wanderer]

... when you reinstall it, it remembers the path so setting the initial path to "C:\Program Files\TotalCmd" ....

this settings is AFAIK stored in the windows registry. Why not store it in "Common Appdata". The exact location of this directory can be obtained through the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Appdata
Maybe there are also API functions to retrieve this information.

Nope. It is stored in the INI file. Search for "InstallDir" in wincmd.ini. The only things stored in the registry are the locations of the ini files (AFAIK).

[djk]

Nope. It is stored in the INI file. Search for "InstallDir" in wincmd.ini. The only things stored in the registry are the locations of the ini files (AFAIK).

Well, I have three items:
- FtpIniName
- IniFileName
- InstallDir

[wanderer]

Nope. It is stored in the INI file. Search for "InstallDir" in wincmd.ini. The only things stored in the registry are the locations of the ini files (AFAIK).

Well, I have three items:
- FtpIniName
- IniFileName
- InstallDir

Ok, maybe things got mixed up. Here is an explanation of how they are working now:

The dir in which TCmd has been installed, is stored in the wincmd.ini file, the setting is "InstallDir".

FtpIniName and IniFileName locations are stored in the registry. It is the only way for the location of the files to be found (since they can be stored everywhere). The only other way would be to create another ini file just to set where the FtpIniName and IniFileName have been stored (which is impractical). IMHO, the registry for those settings cannot be avoided, unless Christian decides to follow a default.ini and user.ini solution and decides that the default.ini file will always reside in the program dir or in windows dir. In that case, he could place the location of the user.ini files in the default.ini and not use the registry.

[apanjocko]

i love it when programs are located and fully isolated in one folder. it makes it so easy to move it somewhere else. there should be punishment for using the registry (public toilet, hack for lazy people, etc. ) when not needed.

however, if something should get upgraded it's from ini to xml. but since that doesn't accomplish much atm. except for nicer structuring possibilities i think it's really low priority.

it's nice as it is, except for maybe that it ain't stored in AppData like it's supposed. but heck, i don't care, i store ini file in program directory

i never backup my registry, becuase there is nothing of importance to me in there - nothing that wont be reinserted at a windows install. using the registry would give me more trouble and cripple me.

i can't believe someone likes the registry, no, i actually can't believe it (from a user's AND programmer's perspective). BAD people.

[Aezay]

For information on the 3 registry string TotalCmd uses, look here: Registry path to wincmd.ini.

I agree on the registry to be a bad place to save program settings, those should IMO be saved in the installation dir.

Talking so much about the registry, I can just as well make some self promo: Registry Commander.

[Gingo]

The big question is are there still users out there using the 16bit version? I'm very curious about it.

Since my home computer is a 486 DX2 66MHz (I think it's DX2, can never remember which) I mainly run Norton Commander, but occasionally I fire up Windows 3.11 for Workgroups (I don't have any network, it just happened to be that version) and use Total Commander 16-bit with joy. I also use Word 2.0 when I write stuff.

[Gingo]

Talking so much about the registry, I can just as well make some self promo: Registry Commander.

Hey, I use that!

[ghisler(Author)]

Some of you have asked why I'm using INI files. There are several reasons:
- historical reasons (sharing of settings with older versions)
- it's more user-friendly to edit and backup
- users can have multiple different ini files (via command line switches)
- Microsoft themselves recommend to store larger amounts of data in external files, and only a pointer to them in the registry
- ini files can be shared between multi-boot systems, e.g. multiple versions of Windows

The locations offered in the installer are not all you can define - for example, you can choose
%USERPROFILE%\Application Data\Total Commander
if you want. I chose not to use "Application Data" because it's a hidden dir.

[Aezay]

Talking so much about the registry, I can just as well make some self promo: Registry Commander.

Hey, I use that!

Oh, so you are the one who downloaded it

[havanna]

I'm in favour of INI as well.
My TC and it's settings follow me to my customers on CD. Fast, efficient.
I'm using 16 bit as well.
Registry was a good idea, but it's not ttidy and it's not easy and many programers enjoy it's usefulness to make things complicated.
And, yes, there are many reasons for multiple user accounts.

The way Christian handles it may not be the best, but I think it's a good way.