Comments about TCmd's configuration files (INIs)

[jb]

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!

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

Wrong.

2. ini files doesn't allows to store multilingual data (unicode)

Unicode is long-awaited feature. So this point is just one more reason to implement unicode support.

3. ini files allows to enter nonsens data( strings instead of digits, p.e)

Wrong. Although the Windows registry has a few data types, also the registry allows you to enter nonsense data.

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.

5. ini files cannot be protected from unauthorized access.

Wrong.

[djk]

Nested informations like [DirMenu] should better be stored in a XML file.

I think it would be also a good solution for fsplugin.ini and lsplugin.ini

I can't believe that somebody puts MS-DOS on the same quality level as TC.

It was a little bit a joke and I don't meant quality but rather frequency of using. I as often use DOS as TC

I don't now how old are you but I've been working with DOS for a such long time now that I can't imagine world without DOS Our company still develop DOS software so I use it really often.

[VadiMGP]

2jb All items above are correct. And i know companies who paid very high price for their delusions.

But i didn't understand something:

2. ini files doesn't allows to store multilingual data (unicode)

Unicode is long-awaited feature. So this point is just one more reason to implement unicode support.

Can you explain, please, what do you mean?

[Lefteous]

2jb All items above are correct. And i know companies who paid very high price for their delusions.

But i didn't understand something:

2. ini files doesn't allows to store multilingual data (unicode)

Unicode is long-awaited feature. So this point is just one more reason to implement unicode support.

Can you explain, please, what do you mean?

0000B1A8h 413 GetProfileIntA
0000A56Ch 414 GetProfileIntW
000502FBh 415 GetProfileSectionA
00034A3Ch 416 GetProfileSectionW
000092F4h 417 GetProfileStringA
00009593h 418 GetProfileStringW
00031399h 904 WritePrivateProfileSectionA
004FF93h 905 WritePrivateProfileSectionW
00008D7Eh 906 WritePrivateProfileStringA
00008DC5h 907 WritePrivateProfileStringW
000500F3h 908 WritePrivateProfileStructA
000501EEh 909 WritePrivateProfileStructW

and so on

(extracted using the excellent FileInfo plugin )

do you still beleave INI-files cannot be writen in Unicode mode:?:
And even if there would't be any native support for storing/loading INI files in Unicode mode, it would be possible to write these functions to support Unicode mode.

[jb]

See next post. Sorry, I clicked quote instead of edit.

[jb]

All items above are correct. And i know companies who paid very high price for their delusions.

Please tell me more about these delusions. I would really like to learn what is correct in all your items above, provided it is related to Windows built on NT Technology (NT 4, NT 5 = Windows 2000, NT 6 = Windows XP). Stuff concerning Windows 9x (based on messy old DOS) is quite irrelevant or will be soon.

Can you explain, please, what do you mean?

Many posts in this forum already addressed (directly or indirectly) the lack of Unicode support by TC. As far as I remember also Christian wrote that Unicode support is on his wish list (partly already announced for TC V6.0!). Full Unicode support would mean that every string can (or even must?) be a Unicode string. So every TC-related text file (such as .ini, .bar and .mnu files) could consist of Unicode characters.

[VadiMGP]

Please tell me more about these delusions. I would really like to learn what is correct in all your items above...

Sorry, explanation of all of them could be really long story and not related to this forum. But anyway i'll give you one short example about "unicode support" in INI fiels. Many programmers think that exists correlation between unicode function interface and file content. Wrong! Compile code below and execute it on Windows 2000. After this check if file test.ini contains unicode text or not. If you think this file will be unicode, surprise awaiting you.

Code: Select all

int main(int argc, char* argv[])
{
	HANDLE hf;

	hf=CreateFile("c:\\test.ini",
	GENERIC_WRITE,
	FILE_SHARE_WRITE,
	NULL,
	OPEN_ALWAYS,
	FILE_ATTRIBUTE_NORMAL,
	NULL);

	CloseHandle(hf);

	WritePrivateProfileStringW(
	L"section",
	L"key",
	L"value",
	L"c:\\test.ini");
	return 0;
}

Experience is the best teacher.

Sorry but it is really impossible in one short post write all incompatibilities and Windows pitfalls detected during many years. And keyword there is detected.

Well, returning back to the start. What you think about Registry as place to store settings? And about XML? I think XML even more dangerous for unexperienced user than ini files.

[Lefteous]

Please tell me more about these delusions. I would really like to learn what is correct in all your items above...

Sorry, explanation of all of them could be really long story and not related to this forum. But anyway i'll give you one short example about "unicode support" in INI fiels. Many programmers think that exists correlation between unicode function interface and file content. Wrong! Compile code below and execute it on Windows 2000. After this check if file test.ini contains unicode text or not. If you think this file will be unicode, surprise awaiting you.

Code: Select all

int main(int argc, char* argv[])
{
	HANDLE hf;

	hf=CreateFile("c:\\test.ini",
	GENERIC_WRITE,
	FILE_SHARE_WRITE,
	NULL,
	OPEN_ALWAYS,
	FILE_ATTRIBUTE_NORMAL,
	NULL);

	CloseHandle(hf);

	WritePrivateProfileStringW(
	L"section",
	L"key",
	L"value",
	L"c:\\test.ini");
	return 0;
}

Experience is the best teacher.

Sorry but it is really impossible in one short post write all incompatibilities and Windows pitfalls detected during many years. And keyword there is detected.

Well, returning back to the start. What you think about Registry as place to store settings? And about XML? I think XML even more dangerous for unexperienced user than ini files.

Code: Select all

#define UNICODE
#include <windows.h>
#include <tchar.h>

int _tmain (int argc, LPTSTR argv [])
{
	DWORD nOut;
	TCHAR uBuffer [1];
	HANDLE handle;
	handle=CreateFile(
		TEXT("c:\\test.ini"), 
		GENERIC_WRITE, 
		FILE_SHARE_WRITE, 
		NULL,
		OPEN_ALWAYS, 
		FILE_ATTRIBUTE_NORMAL, 
		NULL);
	uBuffer[0] = 0xFEFF;
	WriteFile (handle, uBuffer, 2, &nOut, NULL);
	CloseHandle(handle); 
	WritePrivateProfileString(
		TEXT("section"), 
		TEXT("key"), 
		TEXT("value"), 
		TEXT("c:\\test.ini")); 
	return 0;
}

[jb]

If you think this file will be unicode, surprise awaiting you.

Thank you for the tip! As Lefteous has shown there is a simple workaround. Furthermore in the company I work for we use our own IniFile class which is more flexible than the corresponding Win32-API functions and which is part of a multi-platform library. Now you gave us one more reason that we do the right thing, although Unicode is not yet a requirement for our .ini files.

Well, returning back to the start. What you think about Registry as place to store settings? And about XML? I think XML even more dangerous for unexperienced user than ini files.

I clearly prefer .ini files to the Windows registry mainly because .ini files are more user-friendly (easier to edit, backup, copy, move, ...) and they work on any platform (makes porting TC to Linux easier).

I don't know XML well, but it seems to be attractive. For instance my favorite editor saves its settings in XML. A drawback is that XML files are not that easy to edit with a normal editor.

[VadiMGP]

Thank you for the tip!

Not at all. You are welcome!

As Lefteous has shown there is a simple workaround.

Unfortunately this partially workaround applicable only for this small and absolutely useless program. In the real life it doesn't solve any problem.

Furthermore in the company I work for we use our own IniFile class which is more flexible than the corresponding Win32-API functions and which is part of a multi-platform library. Now you gave us one more reason that we do the right thing, although Unicode is not yet a requirement for our .ini files.

Without any doubth it is right decision! If this issue interesting for you, i recommend to take a look at High Performance Solution Ini File Class with MMF from Codeguru site.

[Lefteous]

Unfortunately this partially workaround applicable only for this small and absolutely useless program. In the real life it doesn't solve any problem.

It seems to me as if you don't have any idea at all. Every valid unicode text file needs a BOM (byte order mask) at the beginnend.
Use notepad to verify!
All of your statements about Unicode were wrong...
And of course my solution can be used in a real life application, why not?
It just shows you were wrong. I added 2 lines of code to make it work... so it's a little bit stupid to say it's a partially workaround

[jb]

Unfortunately this partially workaround applicable only for this small and absolutely useless program. In the real life it doesn't solve any problem.

I think that's not fair. After all it is the basis of a solution. It's up to the reader to refine it, for instance by encapsulating the TEXT() calls.
Furthermore it proves that your objection

"2. ini files doesn't allows to store multilingual data (unicode)"

is untenable.

If this issue interesting for you, i recommend to take a look at High Performance Solution Ini File Class with MMF from Codeguru site.

Thanks! Seems interesting. I will look at it in details before the next revision of our IniFile class.

[Lefteous]

Unfortunately this partially workaround applicable only for this small and absolutely useless program. In the real life it doesn't solve any problem.

I think that's not fair. After all it is the basis of a solution. It's up to the reader to refine it, for instance by encapsulating the TEXT() calls.
Furthermore it proves that your objection

"2. ini files doesn't allows to store multilingual data (unicode)"

is untenable.

If this issue interesting for you, i recommend to take a look at High Performance Solution Ini File Class with MMF from Codeguru site.

Thanks! Seems interesting. I will look at it in details before the next revision of our IniFile class.

The "TEXT" or "L" macro is used to make a hard-coded Unicode string. It's unlikely to see to it in an Application were string are read from language files. The example is just to demonstrate WritePrivateProfileStringW works fine for Unicode, if you know how to use it and what Unicode is.

Well, of course there are many advanced INI file solutions out there. But I really don't think it's necessary and has a disadvantage. My Wincmd.ini has 600 lines the Winftp.ini has 200 lines. ...
When using an alternative solution Totalcmd.exe grows. To call the existing windows functions should be absolutely sufficient for the task.

[jb]

Sorry I was too fast. My post was completely wrong.

[wanderer]

Geez! I don't take a look at the forum for a weekend and the thread becomes 3 pages long! Too many opinions posted here so far so commenting on specific posts is pointless. I would like to clarify a couple of things though.

First of all, everything i proposed about the locations of things stands for the initial installation. If the first time you install TCmd you place it on "Q:\TheBestProgramOutThere", when you reinstall it, it remembers the path so setting the initial path to "C:\Program Files\TotalCmd" doesn't really stop anyone from placing it in another dir and it makes it more standard. Ok norfie, perhaps it was not very wise to say that MS people stick to the standards they set but look at the "Program Files" thing. More than 95% of the programs out there have their initial installation path set to "C:\Program Files". That should say something. Look at the "My Documents" path. It hasn't changed it's logic since Win95. Maybe the location has changed (because WinNT is a real OS, unlike the Win9x series which was a poor emulation of an OS) but all programs use a standard Windows API function to find the "My Documents" path, which hasn't changed though Windows versions.

As for the "C:\Documents and Settings\<USER>\Application Data\TotalCmd", whoever has used this dir and has seen how other applications store their files there, he will understand my point. No application stores its data files in "C:\Documents and Settings\<USER>" dir (or at least no one should). If you wish to store the toolbars or other things too, where shoud you put them? Under "C:\Documents and Settings\<USER>" too? Do you know what would happen if every application did that? A great mess like the "C:\WinNT\System32" dir where every application stores their DLLs there and when you try to find anything, you need 3 maps and a guide to show you the way!

Registry: yes it has become the trashbin of modern PCs (as was correctly mentioned by JackFoo) but i believe it's helpful (occasionally). In addition to all pros VadiMGP mentioned, it provides an organized way to store settings (when properly used) regardles of the installation location of the program. I like it because it gives the ability to logically organize things in folders (unlike the ini files), which is visually more understandable than a flat INI file. One could say that INIs are sort-of one-dimensional while registry is two-dimensional. That doesn't mean that INIs are bad. On the contrary, in programs like TCmd, its best to store everything in an INI rather than the registry. As a conclusion, i too believe the best way to go with TCmd's settings are the ini files.