Raymond has a good article listing the reasons why INI files aren’t good enough, and so Microsoft invented the registry.
Why are INI files deprecated in favor of the registry?
I think it’s a good summary, although it is very one-sided. He leaves out all the disadvantages the registry has introduced.
There are a few good comments after the article, but they get lost with all the spam and trolls Raymond’s blog attracts.
“… the possibility to migrate 100% of an application and all of its settings intact, from one Windows PC to another Windows PC”
“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
- modify a config file by hand, quick and dirty style.”
“I have found the registry to be unreliable due to corruption.”
“…[a tool that] tracks which applications touched what registry entries and could strip unneeded ones on an app uninstall”
“No sane user-visible tool for manipulating registry entries. That is — manipulating the registry is foremost a programming interface. Regedit is not even 1/10 of what is needed for even a knowledgeable person to make edits easily”
“XCOPY + INI solves 99% of the problems:
1)Application failure -> XCOPY (whole app or ini only)
2)Uninstall -> DELETE
3)Backup -> COPY *.ini d:\myappbackup\, zip it if needed.”
“I *do* think the migration problems are real. If I want to back up my program settings and reinstall, I know how to do that on Unix for the most part. Backing up /home/evan does most of the trick, and backing up /etc does pretty much all of the rest.”
And Raymond’s snarky reply: [HKCU backs up your user, HKLM backs up your system. Restoring it is a big more problematic, because you have to merge changes, but this too can be done. -Raymond]
Problematic indeed…
A long comment here, but very good, plus Raymond’s snarky reply:
“The Registry is, for all its other benefits, a proprietary solution … And by that, I mean that there’s a fairly short, finite list of tools that can work with it, and pretty much all of them depend on the Windows kernel.
Why is this bad? Maybe if you’ve never had to fix a broken Windows box, you wouldn’t know. When you have a Windows box that is currently unbootable because some random program ate the Registry, your main option, in most cases, is to reformat the machine and start over, not because of the lack of logs, not because of the lack of audits, but because there’s no way to get into the system, manually fix the damage in the Registry, and continue life normally.
Contrast this with Un*x’s .conf files, where you can boot off a CD or even via a network and use any of ten thousand different text editors to edit the .conf files until the system is functional again.”
Raymonds comment - [Said clue was caught years ago. Boot Windows off a CD (use WinPE) and then run regedit from the CD. -Raymond]
Oh how frustrating to get a reply like that! The Raymond haters have just increased.
Fortunately, the commenter had some backbone and replied:
“I’m sure that’s just ducky if you’re in a corporate environment and have access to a Volume License that includes WinPE. So what do you have to tell those of us who are asked to repair aunt Sally’s desktop PC while we’re visiting her on vacation?
Actually, okay, WinPE 2.0 is available to the public now … but prior to THIS YEAR, you really did have to have a corporate Volume License … Hence the existence of third-party solutions, each more hacky than the next. I wouldn’t exactly call that a viable solution “years ago.”
Would it really have killed you guys to include even a marginally-functional RegEdit on the Windows XP Install CD?”
Also in reply to his comment:
“Does that contain a tool to fix any structural damage to the registry? Like fsck or scandisk for filesystems? Damaged .conf files can be repaired easily, worst case you could rewrite the whole file from scratch with the help of a man page. How do you fix a mutilated registry file?”
Personally, I think the biggest problem is the lack of tools. A huge proprietary database, with no elegant tools for:
- modification
- clean up
- backup/restore/merge
- defrag
- damage recovery
which just makes it a big black box, that continues to increase in size for the life of the machine, continues to slow down until the system is completely useless, at which point your only choice is to re-install the OS from scratch. I’ve seen this scenario more times than I can count. It’s what gives Windows a bad name.
It really needs the tools to combat this problem.
I have to say, I think Apple presented a best of both worlds solution for Application preferences. Their ‘database’ for each application is effectively two preference directories: one in the /Library/Preferences and one in ~/Library/Preferences. Technically there is also a /System/Library for the OS, but currently there is no Prerferences directory located there.
Inside these directories are reverse-domain-named .plist files. Plist stands for “property list”, and it is effectively a XML structure file (modified from the original NextStep plist test files). The structure provides Unicode strings, numbers, dates, and even arrays and dictionaries.
That said, the current recommendation is a binary version of this, addressing the parsing speed issue. But fear not, apple open sourced their libraries for handling plists (as part of the BSD licensed Darwin source release) and their binary counterparts. Not only does this provide a standard interface for accessing the files, but it has lead to many automated and GUI tools for manipulating .plist files.
So to address Raymonds complaints of INI files:
* We get Unicode and structured data.
* Security granularity is provided by different .plist files, and more specifically, standard locations for common security permissions.
Additionally, we have a standard location that is something other than ~/.app/ or ~/.apprc (stupid Unix).
In theory, we have the threading problems with writing data and locking files, but these are generally a good thing. I don’t believe Windows registry is transactional, so I cannot write multiple related keys without risking another app will read a partial state. Grouping data by .plist files implicitly provides that transactional security. Of course this leads to potential denial of service, but the separation of system and user preferences, and the use of different files per application / library, means that the effects are minimized unless you have more widespread problems (e.g., malicious programs with Admin priviledges).
I will say that some applications side-step the .plist format (usually in favor of some legacy format), but at least they still use directories within the ~/Library/Preferences directory. I still know exactly what to back up and exactly where to look if I need to repair / wipe an app’s preferences.
Sounds good. It’s sounds much more manageable than the current Windows registry (except for the reverse-domain part, why do people think that’s a good idea???)
Here’s a quote from the comments that mentions plists as well:
“Apple has an elegant solution, .plist files are basically XML files but can also be in a binary format, there is a command-line utility called ‘plutil’ that can convert them from binary to human readable and vice versa (there is also a GUI editor). Applications using these plist files (through the appropriate API’s) can use both types transparently. If you want to tweak something, just convert it to human readable, and when done tweaking return it to binary if you prefer.”
What is your beef with reverse domains?
It is used to prevent namespace collisions by relying on a shared name authority. Reversing it keeps related entries grouped together when sorted alphabetically. In contrast, Microsoft’s registry relies on the statistically unique UUID, which is anything but human readable or intelligently sorted. Give me reverse domains over that any day.
My beef is that it creates an almost mandatory 3 nested deep directory structure (in the file system!) on every entry, when in most cases, it’s unnecessary. I dislike it from my experience in Java. The nesting there is absurd. You have to drill down farther and farther, just to see the source. No reason that casual source code needs to be quarantined by namespace, 3 levels deeps in the file system. Where’s that source? Double click, double-click, double-click, double-click (am I there yet?), double-click….
Two things… First, you’ve generalized a feature of Java to something that does not apply to what I said about Apple’s preferences. In the case of preferences, the reverse domain name is in the filename, not a directory structure.
As for Java, it not mandatory. It only really concerns Java classes that will be distributed as a library, where the risk of namespace collision is possible. That said, it would certainly be nice if you could collapse some of the unnecessary hierarchy. Something like “edu.usc.ict/saso/nlu/..” or even “edu.usc.ict.saso/nlu/..”. For the purposes of the compiler and compile-in-place development directories, this should not be an significant issue, as the ‘.’ character has a specific meaning in a Java identifier. The extra test to find the correct path (com.example/.. or com/example/..) shouldn’t cost much in a single compile, and could even be cached between compile iterations. After all, a degree of guess and check is already implemented as each entry of a classpath is tested. I would not recommend this convenience inside JAR files, and definitely not on raw .class files across http (who does that anymore anyway?).
Ed,
I think I’m glad I don’t read Raymond’s posts.
There is another point about binary speed that I thought I should bring up. Some programs rely on text files for configuration, but then compile them before use. sendmail and postfix are good examples of programs that do this with their use of map files like “aliases”. This nicely handles transaction level issues too. PHP developers use caching to the same effect as well. Edit code, flush cache to see changes and get compiled speed.
There is another text file format that I’ve recently discovered called YAML (YAML Ain’t Markup Language):
http://www.yaml.org/spec/1.1/
It has all of the benefits of XML without the XML.