And if you’ve installed the Developer tools (they come with the OS X Install disks) Though you may end up never using most of it, once they are installed, .plist files will open up with the Property List Editor application, giving you a very Macintosh way of editing and viewing your plists.
Apple has a nice implementation with their preferences API.
I particularly like the PATH-like behaviour of preference lookups, so you can local overrides of system settings. E.g. first ~/Library/Preferences (per-user) is consulted, then /Library/Preferences (system).
I also like the namespacing of settings in a way that is a bit more human friendly than the Registry. My kingdom for less GUIDs, or what, eh?
You can use command-line tools to modify settings, or just edit the .plist file containing the settings directly (it’s XML, or can be made to be pretty easily).
So the scope of the badness of a broken change is likely just one application, and not your whole system, which is a bonus 
Banish the registry ! Put one application in one directory then you just delete it to get rid of it and all its stuff, without leaving debris and collateral damage in the registry. Have three different versions at once, each corralled in their own directory - no worries with no registry to confuse them with each other.
Single point of failure ? delete or corrupt the registry and you’re screwed, trash an application directory, ini file or modern equivalent and you lose one application which you can copy back.
Hi,
Your article resonated with my opinions on Registry and XML-based config files. It was even more heartening to find a mention about Unix-way of doing things.
Well M$ has copied many wonderful ideas and “rebranded” them. My personal choice for Simple App Settings file would be the plain old INI file.
But a word of caution (from my experience) - when the whole world is following a particular norm, it is the best for us to follow that lest we are branded as lunatics.
So, even if I hate XML (for its overuse) and XML-based App Settings files, I better go the XML way if I am programming in .Net. Otherwise I am sure to be branded as “Dinosaur”.
SQLite anyone?
I am not sure if the main issue is if the registry was a suitable replacement for ini files or not, but rather Microsoft’s habit of forcing developers to implement any new type of innovations it introduces and putting their older technology into obsolesence. While ini files can still be used, there is a feeling of discouragement and at best “lip service” support with their use.
Unix-based systems on the other hand, do not push earlier (notice my change of wording from “older” to “earlier”) technology away, but rather give developers the opportunity to implement new innovations if they so please, all the while keeping earlier technology afloat. For a vast majority of developers, the old adage of “if it ain’t broke, don’t fix it” applies. Software is buggy enough, so why give yourself more headaches than necessary?
Later,
Murdock
How do you resolve DLL Hell?
How about really versioning the DLL’s? No, I mean, REALLY versioning. It won’t matter that there are 3 different copies of COMCTL32.DLL because each version will be different, and apps should have been linked to the library and VERSION that was required. When installing the app, the libraries can go to live in the same user-library space ( “C:\Libraries”, anyone?); installing an application with the same library name and version number does NOTHING because the versions are identical, hence, dynamically linked apps will select the right library and the right version on startup.
Oh, wait, I forgot… /lib already does that.
While I tend to agree with you guys on the horrors of the registry system, I also have to sympathize at least a little with Microsoft. Think about the things you did 20 years ago. Hell, think about your website you made only a year ago. Did you have infinite knowledge of what would be the best way to future-proof your design?
In 20 years, you’ll be looking back on the Linux we have now and reminiscing on the stupid things it does now, too… so let’s move forward, help where we can to get this broken system fixed, and stop with the blame and the hate. It doesn’t help anyone.
Ahem - the registry first appeared in Win 3.11 !
Andy: “Aren’t there Windows API calls that can manipulate .INI files in the same way one can manipulate registry keys?”
Yep. ReadProfileString()/WriteProfileString() work with Win.ini, and ReadPrivateProfileString()/WritePrivateProfileString() work with any .ini file.
“The registry is opaque and binary”.
Are there non-binary alternatives to the registry? No. It’s all binary, underneath.
Is it opaque? No more so than a lot of other formats.
-
Text-files are no more nor less human readable than the registry files. It is all just 0s and 1s. It is just that there are more visualisation / editing tools available for text files. But that is not the fault of the regisrty itself.
-
Yes, you can add comments to XML files and INI files. But you can document registry settings, too. By giving them meaningful names, or in external help files. In some ways this can be better - you can hyperlink a help file. You can’t hyperlink comments in .INI files.
Personally, I don’t see the registry as the problem - or the solution. IMHO, the whole file system should be more like a database. But that is a whole other discussion.
.ini files suck, and should have died with Windows 3.01. Just because coders dont use the Registry correctly/efficiently does not make the registry wrong. Several apps I write use very deep heirarchy settings, trying to parse that into an ini file would be torture, registry is a snap. Plus, most users are dumb enough to delete files as they are easily found, but know the Registry is off limits to newbies, so more secure.
The commercial GUI applications I have prepared use XML for all configuration. If the user blows the configuration file away, a default file is automatically prepared next time the application launches. Why mess with registry unless another process needs to find yours and interact with it? Come to think of it, sometimes that can be done using named pipes.
Microsoft never took away the APIs for manipulating INI files. If the registry is so bad, it leaves one to wonder why developers didn’t revert to using INI files. Perhaps that’s because the registry, for all its warts, is still better than INI files.
A note on .Net config files.
If you’re lucky enough to use the monstrosity that is visual basic, accessing settings is fairly simple using the “My” namespace.
For those using a real language, such as C#, it’s somewhat harder and the VS2005 help files aren’t particularly useful.
Definitely agree. That’s why when I write utility applications I don’t use the registry - my programs write INI files.
If you’re working with an application that runs on a network - an INI file on a network share makes a ton more sense than using registry entries. Wanna change a parameter and have it affect all associated workstations? Make a quick change to that INI an PRESTO … all workstations have the change. With a registry - you must go to each workstation somehow to affect the change.
A central registry hive was, IMHO, a major mistake. It works, yeah, but it’s a horrible throwback to monolithism in an age of modularity. Better to have established a hidden directory under \WINDOWS somewhere and have a bunch of INI files. Much easier to recover from system failures.
-MP
You are correct. The registry (along with COM in general) is one of the most successful failures ever.
What a happier world this would be if in the NT3.51 days Microsoft would have decided to lock the registry down. 
I’m happy to see that ALL the posts agree on the same fact: storing
everything in a single congested place is simply too stupid.
It’s a dumb idea created by not too smart people, just thnking a little about the problem would have led them to find different solutions, even 20 years ago.
The registry is the reason why, in case of crash of my HD, I’ll need more than a week to reinstall everything. And the reason why it takes about 10 minutes to boot win XP, the registry now being a horrible 50 MB monster full of nonsense.
Have you ever tried to cancel by hand the keys of some application? With separated installations and config files it would be a matter of deleting a directory, actually it’s a nightmare of deleting keys one by one by hand, hoping not to miss a single one.
And have you ever seen the useless junk that most applications store in the registry? Maybe the initial idea was that only really valuable information was to be stored, but some apps, an application from Kodak comes to mind, actually insert thousands of keys for a set of applications that mostly I’ll never use. Imagine installing a lot of programs …
Moreover, as far as speed is concerned, I dont’ think the registry is fast at all. It’s a sort of database created with technologies of 20 years ago, so old and slow. Then … how can you compare searching a 10 byte value in a 100 byte file instead of having to search through 50 MB of registry? And if it’s all in memory (I doubt it), why is windows wasting 50 MB of precious memory when I only run my app which needs only a 100 byte configuration?
What I’d really like to find sooner or later is a tweak or driver or hacked DLL for windows that let the apps think they work with a single registry, but actually splits the information locally, the specific one in the same directory of each app. That would really be a useful upgrade of the OS …
Having all configurations in one place (i.e. a registry) is convenient if you need to view/manage all settings as one entity.
Having each configuration in a local place (i.e. an INI file in an app or user folder) is more convenient if you want to view/manage its settings in isolation.
The problem with a hierarchical based system is that it can never serve both purposes simultaneously. In a way its not unlike the issue we might face when deciding how to structure our folders to store documents – you may want to group documents by type (i.e. all your project schedule files) or by author, etc.
SQL-based storage solves many issues by avoiding the imposition of having a single hierarchical view. Perhaps, as others here have suggested, this could be the basis of solving some of the issues associated with the registry.
I still think that applications should be installed by simply copying a folder, but perhaps any related INI-type files would automatically be pulled into the SQL-based system (perhaps on the first execution of the application).
More thought would need to go into this (there are already many caveats I can think of but I think that decent solutions could be found for most issues), and I think having a relational view of configurations could go a long way to serving the best of both worlds.
Importantly, the SQL-based system would need to provide the user with a rich interface that is easy-to-use that allows the user to view/manage/copy any application settings or user settings, etc.
Jeff,
Well said! I have always been less than thrilled about the registry for all the reasons you list above. The Vista registry/filesystem extension is nice BUT, implementing this in an application would involve having two code paths: one for vista, and one for all other Windows OSs. I think a better direction is to migrate application settings into a local xml, or ini file contained next to the applications exe. This would result in one code path, and move a bunch of junk (which applications need to persist) out of the registry.
I think people put too much weight on the official direction provided by Microsoft. I did it ten years ago when I started persisting application settings in the registry.
-jared