Main Area and Open Discussion > General Software Discussion
Why the Windows Registry Exists
Ralf Maximus:
Raymond Chen asks "Why are INI files deprecated in favor of the registry?" then goes on to explain why:
http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx#comments
Basically a big bullet list of why Windows outgrew .INI files.
The registry tried to address these concerns. You might argue whether these were valid concerns to begin with, but the Windows NT folks sure thought they were.
--- End quote ---
Frankly, it makes sense. The NT development team saw a world of commercial software spinning out of control with thousands of unmanaged .INI files crammed into the Windows (well, WinNT) folder and came up with the registry as a solution. Love it, hate it, you're stuck with it -- so here's some salve for your impotent rage: at least now you know WHY they did it.
And as usual, the comments are worth a read as well.
mouser:
I am a hater of the windows registry, but have to give him credit for the best defense of it i've seen.
On the other hand.. this really seems to be advocating for registry vs. HORRIBLE OLD WINDOWS-INI FILE FORMAT.
The real argument should be registry vs. a very well thought out config file format.
Ralf Maximus:
Well, exactly. He's speaking of the early 90's, back when there was palpable panic about what to do about zillions of .INI files. Back then, most apps used the API to manipulate an .INI, and that's where stuff like the 32K limit comes from.
Assuming you're confident yours is the only app that will twiddle your .INI, and you code responsibly, none of the issues he raises are showstoppers. In fact, I *do* store binary data within .INI files, and build nested structures, and on today's hardware it's all buffered intelligently in RAM anyway so there's no performance hit.
However, if you're writing a multitasking operating system (with open support for every 3rd party idiot out there) the concern is very real. Thus something like the registry makes sense. How does Linux or OS X handle configuration stuff?
Still hate it, but once I recognized nobody's forcing me to store my keys there, the hate has settled down to a dull disdain.
Armando:
This guy seems to have good points too (some of them have been mentioned repeatedly here at DC) :
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 :o
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]
--- End quote ---
http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx#6532881
BTW, why is there a 32kb limit for the ini file ?
mwb1100:
BTW, why is there a 32kb limit for the ini file ?
-Armando (November 26, 2007, 11:55 AM)
--- End quote ---
Remember that Raymond Chen is talking about this from the point of view of Windows APIs. The 32KB limit is there because Microsoft made it so in the APIs - probably due to the 64KB segment size limit back in the Win16 days. I'd bet that the limit is 32KB instead of 64KB because the original programmer just happened to use a signed value (with a range of -32758 to 32767) to represent the size instead of an unsigned value, and no one thought that would present a problem because who'd ever need more?
Once programs get written to rely on the 32KB limit (for example because they allocate a buffer of that size), Microsoft is in a bit of a bind - to change something like that they have to either be willing to break some existing programs (almost never a good idea) or they have to come up with a new, parallel API. They haven't done anything to the INI-related APIs because they went to the registry instead. Now they support XML configuration for many things.
Navigation
[0] Message Index
[#] Next page
Go to full version