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.co...523907.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.

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

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 ?

[mwb1100]

BTW, why is there a 32kb limit for the ini file ?

-Armando (November 26, 2007, 11:55 AM)

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.

[app103]

There is a 32kb limit?

Whoops! Someone forgot to tell Opera, AOL, Maxthon, Spybot, Flashget, Sierra, etc.

Why the Windows Registry Exists

That 97kb one is from Opera, which seems to work just fine with an INI file that is 3x the 'limit'. 

[Ralf Maximus]

That 97kb one is from Opera, which seems to work just fine with an INI file that is 3x the 'limit'. 

-app103 (November 26, 2007, 12:30 PM)

Heh.  That's because those programs have stepped outside the Windows API for manipulating .INI files and have rolled their own mechanism.  Exactly what I do.

[Armando]

Yes, I was also asking the question because so many ini files on my system seem to exceed the 32kb limit (farr being one of them...)

[Lashiec]

I remember that back on the 9x days, Notepad couldn't handle text files bigger than 64 KB, and CDPLAYER.INI couldn't store many CDs in there

Excellent post, at least we can finally understand why they choose a registry system instead of .INI files. I wonder if this was some kind of answer to Jeff Atwood's post about the same thing...

Can we move to .XML or custom .CFG files now?

[Gothi[c]]

Can we move to .XML or custom .CFG files now?

Or just read/write your own ini's without the windows api, as mentioned before...

This article is funny.
So basically, Microsoft implemented something in a very horrible way (ini api), then came up with a very horrible alternative (registry), while the rest of the world implemented their own way of dealing with ini files, which is actually not broken like the original api, microsoft is now still pushing their broken registry.

INI files don't support Unicode.

Not in the windows api perhaps, but it's trivial to implement an unicode-compatible ini-reader/writer as many have done before.

INI file security is not granular enough. Since it's just a file, any permissions you set are at the file level, not the key level. You can't say, "Anybody can modify this section, but that section can be modified only by administrators.

Oh, so you're saying that file permissions at the file level are not secure? Bad news for Vista I guess. It's not like registry keys are secure... I'm assuming he's referring to ancient single-user windows. These days it's easy enough to set file permissions so a file can be accessed by only one user, or administrator, just as with registry settings.

Multiple writers to an INI file can result in data loss. Consider two threads that are trying to update an INI file. If they are running simultaneously

I guess they don't use mutexes over at microsoft. No wonder their OS crashes all the time

INI files contain only strings. If you wanted to store binary data, you had to encode it somehow as a string.

As addressed before, it's easy enough to store binary data in an ini...

Parsing an INI file is comparatively slow. Each time you read or write a value in an INI file, the file has to be loaded into memory and parsed.

Again, this is windows API ineffectiveness. Most programs using ini files will read the file, parse ALL strings they need, or if they need to write multiple values, it's easy enough to do so in one write operation.

What's more, many programs that parsed INI files were buggy, so in practice you couldn't store a string longer than about 70 characters in an INI file or you'd cause some other program to crash.

Wait... programs using ini files buggy? Didn't you just say you guys created an API with only a 32KB buffer? Oh yeah, and 640K memory is all you'll ever need, right? Maybe look at your own code first,...

The default location for INI files was the Windows directory! This definitely was bad for Windows NT since only administrators have write permission there.

I haven't seen an app that writes ini files into the windows directory in years,... Most of them are stored in the application's folder or one of it's sub-folders... Which is actually pretty cool. Copy your application folder to an usb-key, and you can use it anywhere with the same settings. Lets see you do that with the registry...

INI files contain only two levels of structure. An INI file consists of sections, and each section consists of strings. You can't put sections inside other sections.

I guess technically you could make an ini with more hierarchy, but it would make more sense to use XML here.

[Added 9am] Central administration of INI files is difficult. Since they can be anywhere in the system, a network administrator can't write a script that asks, "Is everybody using the latest version of Firefox?" They also can't deploy scripts that say "Set everybody's Firefox settings to XYZ and deny write access so they can't change them."

You can do that with the registry? Wow! Isn't firefox always going to be firefox.exe in the same friggin' folder regardless of version? But i guess that's not the point he was making. 100 different apps might use 100 different registry key names for where they store the location to firefox... I guess you could search on the actual filename, and get lots of false positives... but wait, isn't that the same as doing a file search for *.ini containing firefox.exe?

[tinjaw]

There are some many things in life that I just look at and think I must just not be smart enough to understand. But I know that it is just a matter of educating myself and eventually I would understand it. For example, higher level math or physics. However, there are other times when people widely regarded as some of the best minds in a field do something and I just know, without understanding all the high-level intricacies, that it just isn't right. The Windows Registry falls into the latter category. I know there are a lot of very smart people working at Microsoft. A few of them are close friends I made while working other places like Borland. But no line of reasoning or explanation has ever even made me doubt for even a fleeting moment that opening the registry to anything other than the operating system itself was a smart decision.

When the Windows Registry was first explained to me I could only see it in terms of a flat file being moved to a database behind an API. I saw no benefit of doing so. And what's worse is that the core problem, allowing write access to the OS-level configuration details, was still there.

Now, I am not experienced enough to know the details of how to actually implement what I am about to attempt to explain , but the general concept seems solid. The operating system should not allow other programs to make such changes as it currently does. External applications should only be able to request info from the OS and *request* to make changes. It should be up the OS to allow such changes, and it should be part of the contract that the OS, at any time, can reverse itself and deny the request. Along with this, external applications/developers should work on the assumption that such requests will be denied. This, I believe, although I do not know, is more along the lines of how consoles operate.

I think the whole crux of the issue is that Windows is *not* just an operating system (ie a kernel and basic services) but is basically a whole suite of middleware on top of and operating system. As such, it needs to do much much more, and thereby causes the need for all of the stuff that cause problems. But I understand that almost all of what makes a general purpose computer more useful than a narrow use console is the ability for the applications to run at the same time and interact. But the true solution to that is difficult to orchestrate, namely, programmers, many many programmers, all producing and API interface to their own programs that is five nines perfect in terms of doing what it claims to do in the manner it claims to do it *and* five nines perfect backward compatibility. Something that is possible but not probable.

In summary, once again, the solution is to cater to the least common denominator, namely the hundred of thousand, if not the millions of bad programmers that work on the system. And that is what Windows, and all its constituent parts is, the least common denominator that will survive the ungodly amounts of crap software that will be installed on it.

[Ralf Maximus]

And that is what Windows, and all its constituent parts is, the least common denominator that will survive the ungodly amounts of crap software that will be installed on it.

Well said, tin!  However flawed, the registry has survived and functioned for 15+ years so the original designers did something right.  Of course, that's like pointing to a 1962 Volvo and saying the same thing -- it may be a crap car but by god it's still running.

And then Gothic sez:

I haven't seen an app that writes ini files into the windows directory in years

Very true.  But consider the perspective of the article: Raymond is writing about decisions made in the early 1990's, and indeed, if an app availed itself of the Windows API then the only place an .INI could go was the Windows (or WinNT) folder.

He's not defending or exhalting the registry, simply explaining how it came to be and some of the problems being faced; why the registry was created.  Taken in that context every one of his points is valid.

Central administration of INI files is difficult. Since they can be anywhere in the system, a network administrator can't write a script that asks, "Is everybody using the latest version of Firefox?" They also can't deploy scripts that say "Set everybody's Firefox settings to XYZ and deny write access so they can't change them."

You can do that with the registry?

Indeed you can.  Permissions willing, Windows allows remote administration of another PC's registry.  RegEdit provides an interface, if you want to play.  And querying the registry for a known key that points to a local file is *way* easier than scanning a remote file system.

Oh, I still hate the registry.  Hate, hate, hate.

But when I sit down to consider what we'd replace it with, I draw a blank.  A collection of .XML files?  How would that be better, aside from being able to edit them with notepad or index them with Desktop Search?  And you'd still have a Windows service to administer them, and yet another dozen API calls to master, so is that an improvement?

And again: how does Linux or OS X manage configuration settings?  Leave it up to each program?

[Gothi[c]]

And again: how does Linux or OS X manage configuration settings?  Leave it up to each program?

On GNU/Linux, system-wide configuration files are in /etc
Applications will typically put their configuration in ~/.appname/config or ~/.appname
Works for me.

But when I sit down to consider what we'd replace it with, I draw a blank.  A collection of .XML files?  How would that be better, aside from being able to edit them with notepad or index them with Desktop Search?

It would be more portable, for one. And having windows crash to hell, requiring a reinstall, wouldn't mean loosing all your settings, for two...

[tinjaw]

And again: how does Linux or OS X manage configuration settings?  Leave it up to each program?

-Ralf Maximus (November 26, 2007, 02:25 PM)

As I did the first time you asked, I assume this is a facetious rhetorical question. But for the benefit of those who don't know the answer... Yes. *nix systems work with text configuration files. Each app has its own (if the app needs such capabilities).

[tinjaw]

I must restate that the whole ini vs registry vs xml vs whatever is a red herring. The *real* problem is that the software running on current day computers are not designed/implemented in the manner they *should* be. Namely, (very) loosely coupled individual components that request, but do not require, other pieces of software - the OS just being another piece of software.

The problem is the interoperability, stupid.

But, such a system is economically viable. It results in bloated redundant software that each become victims of LCD themselves.

There is an example of the other extreme. It is called Apple. Pre-Unix-Apple, but Apple none the less.

[Armando]

If the registry was only used for OS matters, wouldn't it fulfill its purpose better ? But what is that "windows" OS exactly... Like tinjaw said :

I think the whole crux of the issue is that Windows is *not* just an operating system (ie a kernel and basic services) but is basically a whole suite of middleware on top of and operating system. As such, it needs to do much much more, and thereby causes the need for all of the stuff that cause problems.

-tinjaw (November 26, 2007, 02:05 PM)

[Ralf Maximus]

If the registry was only used for OS matters, wouldn't it fulfill its purpose better ? But what is that "windows" OS exactly... Like tinjaw said

-Armando (November 26, 2007, 02:57 PM)

Ooh, that's it.  Perfect.  Let Windows use the registry for infrastructury things and leave everyone else alone. 

In fact, it would've been better if the registery were designated an "unsupported" component, to discourage external meddling.

[nontroppo]

How does Linux or OS X handle configuration stuff?

OS X has something called .plists - they reside in:

/System/Library/Preferences/ - core OS, no playing there José!
/Library/Preferences/ - prefs for all users
~/Library/Preferences/ - prefs for particular user

plists are XML, and can be encoded as a binary format for faster execution if needed. They use a simple namespace mechanism for naming to avoid collisions (e.g. com.apple.dock.plist for Apple's dock preferences). By dragging your user preferences directory around, you can easily migrate your settings (it worked amazingly well on my upgrade to Leopard). The OS provides users with a way to query and edit plists via the commandline or applescript:

defaults write com.apple.dock mouse-over-hilte-stack -boolean YES

There is also a GUI editor which represents them as a DOM. Nothing OS critical is stored in the user accesible plists. You can nuke prefs directories and everything will work fine from internally stored defaults IIUC. Cross-platform apps like Firefox and Opera store prefs in subdirectories, and they use whatever formats they want (Opera still uses its custom INI format on OS X for example).

Registry = Fear and Loathing in HKEY_LOCAL_MACHINE...

[f0dder]

The registry is actually a pretty nice thing, pretty efficient (binary search), and imposes a nice structure (instead of the fugly /etc/* files each more or less with their own syntax), and pretty safe (journalled access).

Ths problem, as always, is really the legacy of Win9x and people used to running with admin privileges, meaning that applications are accessing locations they shouldn't. And people (including Microsoft themselves) storing information that shouldn't be stored.

NT uses "hive files" for branches of the registry, so you can already backup per-user registry settings. Problem is that the "Documents and Settings" folder structure has a horrible layout, and the files aren't as obvious to get at as they could be. A hive file per application could be a pretty interesting idea, with the addition of an application being able to use either the default hive or specify it's own custom location - this should already be possible, really, but requires some API calls that most developers aren't familiar with.

But because the world looks like it does, I personally do prefer .xml files and the ability to store either per-user in %APPDATA% or (portable mode) the application folder, even though the registry is technically superior.