Rune
JM’s remark about each user getting their own file was a response to the claim that using INI files had locking issues, he wasn’t talking about the registry in that case.
Dude, I’ve been a fan of your blog for the past year, but ever since you started advertising, your posts have been really really boring. I’m sorry but I’m getting ready to hit the unsubscribe button.
This remind me of a talk channel9 did with Rob Short, who I believe in this interview covers why he created the registry, and his thoughts on the topic.
Indeed, the registry does suck. Game developers probably store the CD-Key and area code for the nearest burger king (oops dev error!) because normal users who want to look cool by opening up cd-key.ini and changing it just end up screwing things up anyway. I guess it’s a saftey thing ( or not because a link to the registry is in the start menu 
)?
Peter Wilson is absolutely correct. The other reasons may be secondary benefits, but the real purpose of the registry is control. We’re computer geeks, so we evaluate things by their coolness; most people are about social domination and being top dog. (Look at the Pew Center studies on happiness and income for one aspect of this.)
A bunch of text/xml files is better than this registry things, yes. Either way, only power users are going to touch these things, and power users will be happier with easy to maniuplate and move around text files.
The issue then is to have those text files in a simple, logical location. For this to work, you need very straightforward simple APIs. And I do agree that Mac OS X got it right on both counts: the pref system is very logical and flexible. And the APIs are so simple, e.g. in ObjC:
[[NSUserDefaults sharedDefaults] setValue:someObject forKey:@“SomeSettingKey”];
mypref = [[NSUserDefaults sharedDefaults] valueForKey:@“SomeSettingKey”];
where someObject can be a string, a hash, an array, a number, or any object that has an serialize method defined.
I don’t have a problem with the OS itself using the registry, but I would prefer per user application settings to be saved as a configuration files in my home directory. This makes them easier to backup, and easier to delete when I decide to restart from scratch.
I haven’t used Visual Studio for a while, or MFC, but the apps that were generated created a registry entry for each different project. Since I was working through several books, I created over a hundred projects. Sure enough, that meant over 100 registry entries.
And every demo program you download creates dozens of entries.
“binary blob of data”
That’s what I call redundancy.
“binary blob of data”
That’s what I call redundancy.
Thts wht I cll rdndncy
You’re BEGINNING to wonder??
I wrote one small app that used the registry. I learned my lesson, I haven’t touched the registry since unless I need to inform Windows about something.
As for the comments about locking and .ini files, there are cases where it’s needed. An .ini on your own machine isn’t going to be an issue but a network app that maintains a configuration on a server could realistically be hit by multiple people and thus needs protection.
I’m pretty terrified to see all the comments here advocating storing settings in the same folder as the application (in Program Files). I’m guessing you guys are the ones that write apps that need Administrator privileges to run because you think apps have write permissions to their install directory. And your apps don’t work on multi-user machines, either.
The user’s AppData folder is the only good place to put app settings.
Regarding the article: AMEN BROTHER.
A quick note for those of us who, like me, wondered what “LocalLow” was about? I dug down (ha ha) into it and found this:
<a href="http://msdn2.microsoft.com/en-us/library/bb625960.aspx">http://msdn2.microsoft.com/en-us/library/bb625960.aspx</a>
The executive summary is: LocalLow is where applications running at a “low integrity level”, that is, not fully trusted, can store local settings. These processes do not have write access to “Local”. (Although, from what I understand, they have read access.)
With all the negatives around, here are some positives:
-
The registry has a hidden backup which the OS keeps in Sync with the main one. If the main gets corrupted, the backup kicks in. It’s also easier for backup software to backup the regsitry for you. Even programs like 'Spybot - Search Destroy" do it for you.
-
Fire regmon.exe and look at all the calls going on. If we had ini files scattered all over the drives and the system continously reads them, it will slow down the system.
-
I never had a problem with editing the registry. Export the key you’re going to edit and do your edits. If you screw up, import the export file. Simple and easy.
-
Control using permissions. It’s not easy to change permissions like on the file system
-
A single place to search for a key or value whose location you don’t know.
-
There are tools out there that can delete orphan entries.
-
Registry offers control for casual users. You don’t want them editing ini/xml files just because they are text files.
I think a hybrid system is best. Let the OS use the registry for itself and the applications can use their own settings which are placed in the app’s folder.
This was another example of Microsoft taking an idea from someone else and implementing it in the worst possible fashion.
NeXTstep (and OS X now) had the defaults command to read/write preferences, but each app has it’s own file, so if one program screws up, it only screws up it’s own preferences.
And the culture on OS X is that if you don’t find any preferences, you write new default preferences, unlike windows where most apps, if they don’t see any preferences, throw up their hands and just exit.
I think the registry wouldn’t be a horrible mess like it is now if the write access to it programmatically was more limited. Ie. let apps only write to some specific area for app data storage.
In theory storing things in a single registry-like place is a good idea. The Singleton/Storage/Registry/whatever design pattern, anyone?
Someone mentioned the fact that the registry is backed up. That is actually a very good point in favor of using it. Hadn’t thought about that.
I happened to be at the 1st Windows NT developer conference back around 1990. During a Q/A session after a presentation on the registry (introduced with NT, not Windows 95) I stood up and asked whether the system would contain any useful metadata. I had been mentally comparing it to Apple’s system of resource forks and decided at the time that it was a disaster in the making. The answer as no. I can’t remember exactly what else I said but it was something to the effect that “this will be a disaster without decent and consistent and auditable metadata.”
If you don’t know what metadata is, please disqualify yourself from replying to me or commenting on the registry design feature; it will save us all a lot of time.
Well Duh, the registry sucks.
Abuse of the registry sucks. And perhaps the original design was flawed, in that public access was allowed to the innards of the registry from day one.
The point of this post isn’t entirely to pile on the many faults of the Windows Registry. Discussion of alternatives is useful; even in UNIX, you need a place to put centralized settings. You could even defend the registry as a useful construct for certain tasks.
We’re trapped in an abusive relationship with the Windows Registry. The question we should be asking ourselves is “as software developers, how can we change or fix this”?
KG @ 3:47pm hit the nail on the head.
Always remember that Windows and Office are designed primarily for enterprise customers. If something in Windows makes life a bit easier for corporate network admins but hell for home users, Microsoft will choose to screw the home users every time.
Note that Microsoft products that don’t have the baggage of serving the enterprise market (Xbox) are actually quite good.