Recent Posts1901
General Software Discussion / Re: Why the Windows Registry Exists
« Last post by Armando on November 26, 2007, 11:55 AM »This guy seems to have good points too (some of them have been mentioned repeatedly here at DC) :
http://blogs.msdn.co...6523907.aspx#6532881
BTW, why is there a 32kb limit for the ini file ?
re: Why are INI files deprecated in favor of the registry?
Monday, November 26, 2007 11:58 AM by Felix Koehler
Well, ini files (meaning .ini, .xml, etc.) obviously have disadvantages. But they also have advantages.
You can easily fit all program + configuration into a single directory, which allows
- "an application on a memory stick",
- "an application without installer",
- "an application with very limited rights" (write and write only one directory, no registry access allowed),
- multiple versions to exist peacefully without any clever thoughts along the lines: "gee, what else did I forget that gets silently overwritten by the installer.",
- modify a config file by hand, quick and dirty style.
- config files can be defragmented on disk easily
As for the disadvantages - these are curable with some effort (well: effort is a disadvantage in itself ;-)):
- read / write race conditions can be handled in a variety of ways:
+ lock the file
+ use Mutexes
+ allow only one instance at a time
+ work on a temp. copy.
- denial of service:
+ Kind of an "other side of an airtight hatch" problem. Basically any program that can lock an arbitrary file will be able to do a DOS-attack.
- security granularity:
partitioning of the "one big inifiles" into several small ones with different ACLs allows to circumvent this.
- parsing is slow:
There's no cure against access being O(N), other than making sure N is small. So split them up. smaller files -> faster parsing.
- INI files contain only two levels of structure.
again, split them up into several files, if necessary use a directory hierarchy
- .ini files are 32kB max:
call them .conf files and use your own parser
- The default location for INI files was the Windows directory!
And 640 kB used to be enough for everybody (This is no sarcasm. Back then it *really* was). But that's a sin from the past, ini-files went through rehab and don't do this anymore (well ... it's hard to stay clean for some ;-)
- ini files contain only strings:
ini-files are definitely not meant to contain large quantities of binary data. ASCII-encoding is good enough for small quantities though.
- no UNICODE support:
unless you insist on using the windows API for handling inilike-files, I don't see the problem?
- handwritten parsers are flaky:
Yes. On the other hand, the ini-file format is simple enough to write your own little API and test it adequately. And using std::getline and std::string, I haven't yet seen any buffer overruns.
So IMVHO the only real disadvantage of ini-files & co. is that it's more effort to implement compared to using the registry.
Oh, and it's much harder to hide information from the user (Time limited test versions anyone?). Though, XML files can be at least as good at obfuscation as is the registry ;-)
As a user, I *like* config/ini - files.
Felix
[I like argument through assertion. "You won't have any buggy INI file parsers if you don't write buggy INI file parsers." And argument through blame-shifting: "You can avoid the race conditions by introducing a denial of service attack." And then argument through discount: "Yes, there's a denial of service attack, tough. You didn't care about central administration anyway." -Raymond]
http://blogs.msdn.co...6523907.aspx#6532881
BTW, why is there a 32kb limit for the ini file ?
