The Old New Thing

The granularity "issue" is sidestepped in a lot of cases by allowing XML files to refer to (or include) other files.  XInclude is a decent way to do this, but there are other ways as well (e.g. .net's .config files let you include other files using custom attributes on several elements).  If you refer to a different file, that different file can have a different ACL on it.

Now, this is obviously bad if you want fourteen layers of XML elements with different ACLs at each layer.  But that seems to be rare, at least; the most common usages seem to be where you have to store database connection strings and the like.

(Another solution is to encrypt sections of the file, e.g. with some of the XML security extensions.  Make sure you'll be able to decrypt them, though, and make sure you don't use a hardcoded key.  Using the current user's (preferred) or the machine's (less preferred, but the only option if you run as localsystem) crypto key is usually a much better idea.)

On a different point: Even if you did have to worry about multiple writers, can't you just lock the file while doing the read-modify-write cycle?  Yes, it's worse for efficiency, but the registry has to do something similar anyway, I think, since hives are stored in files.  Plus the registry code is in advapi32, which gets loaded into each process independently, so you don't have a central service (or whatever) to arbitrate access.

@BryanK: there is a central registry "service"; advapi32 is just an interface to the kernel registry functions.  How would the security work otherwise?

Isn't another advantage of the registry is the ability to track changes and roll them back?

I still really hate the registry and for two main reasons - abuse and cleanup.  Applications fill it with too much data and applications leave too much behind when uninstalled.

I haven't considered upgrading from XP and I likely won't for years (if ever) because I don't like ANY of the changes in Vista.  Suppose however, Microsoft would announce an upgrade to Vista that tracks which applications touched what registry entries and could strip unneeded ones on an app uninstall (or at least make it convenient for me to do so)...

I'd ditch XP and upgrade to Vista for that reason alone - damn any other complaints I might have.   The registry has been that big of a bug crawling around in my shorts since its inception.

Bob,

Programs leave registry data behind for the same reason they left behind .ini files back in the Windows 3.1 days: so that if you re-install the application, your preferences from before are remembered.

Some uninstallers are nice and actually ask you if you want to delete settings along with the rest of the app, but I'd be angry if they assumed you always wanted to delete settings. Especially with flakey apps like Apple's iTunes (on Windows; it's fine on OS X) that need to be reinstalled often.

The registry is a superior solution compared to text or XML files, agreed. And it is the best solution for storing information in a central, well formed manner, like for the COM classes and the Plug and play hardware enumeration stuff.

But I'll trade all the disadvantages with text/XML files (as compared to the registry) for one important thing: the possibility to migrate 100% of an application and all of its settings (e.g. registration) intact, from one Windows PC to another Windows PC.

Because once an application has written its particular set of data in the registry, it is not always clear how to retrieve all of it. Unless you happen to be the application developer, the registry will seem like a giant bit bucket in this case.

If the NT designers had designed writing to registry so, that the information given by GetModuleFileName() were written along with the data keys, then the Export function in Regedit could have been so much more powerful. I.e. if I could specify a file path, like C:\Program Files\My Company\My app, and tell Regedit to export all of the data tagged with this path, then it would be possible to copy 100% of an app to another PC as easily as this is done today with text/XML config files.

Rgrds /Henry

James,

There's a reason I uninstall most applications - they are garbage.  I don't want my preferences remembered when I'm chucking the software.  I would say those programs think too highly of themselves, but I doubt seriously that the programs are leaving the registry data behind for me and re-installs.  I bet 99% do it only because of the time, money, effort involved in coding the total removal.

Also I'll note that most of the applications with nice uninstallers tend to forget anywhere from a few to a lot of keys.  They usually get all the ones placed in the registry on program install but miss most if not all keys created during the program's operation.

Of course the entries that that peeve me most are all the objects, clsids, and the like - things that can't be trimmed by removing one big program branch.  Unfortunately these are the very kinds of entries that continue to wreak havoc on computer operation.

@Henry: I don't think that that's such a good idea. Unless NT would make sure that files aren't really stored in directories and can be "tracked" properly. IMHO Windows should make it easier to move programs around, just like on a Mac where it doesn't matter where you put an app and if you rearrange them, they'll still work.

Programs written for POSIX systems are in this regard an even bigger "mess", since they use a /bin, /etc, /lib, etc. This is all fine in any *nix OS and I'm glad they work the way they do, but in a desktop system this doesn't help much, and could be done better.

Bob:  Abuse and cleanup are each program's fault, not the structure's fault or Microsoft's fault.  

To people who want to get rid of the registry completely:  What would you replace it with?  INI files?

Henry:  In the old, old days, you could usually migrate an application by copying the (one) EXE file and its INI file (assuming you were properly licensed, which some people ignored).  

Today, you need to reinstall the application anyway, since most applications of any complexity will register DLLs and so on, so you need to use the installer.  Copying the application's program files folder isn't enough.  A well-behaved application will let you export and import its settings.  If the applicaiton doesn't provide this, it's not the fault of the designers of the registry.

When you say that you want to migrate an application's "registration", what do you mean?  Registration generally means licensing and so on, and you SHOULD have to go through registration again on a new computer.

Otherwise, you have created the ability to buy one copy of a program and install it on 1000 computers.  It's possible to violate a license agreement, but it shouldn't be made trivial to do.

Being able to copy 100% of an app to another PC is not something that needs to be optimized.

David: I think "registration" was referring to things like COM registrations. Licensing is tangential. I agree, though, that app migration is nightmarish under the current Windows development model. COM probably thwarted more would-be pirates than WGA ever did.

What's really needed is the ability to audit registry changes based on program, which I suspect is not possible with built-in Windows functionality.  On the surface, this might seem reasonable; however, things would get tricky if audited-program-A asks trusted, non-audited-program-B to make a change to the registry.  I'm not sure if this actually happens, or if programs directly always directly access the registry.  I am fairly sure that one would have to be fairly restrictive in what is audited, to avoid performance and log size issues.

Note that one can monitor registry access with SysInternals' Process Monitor: http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx .  I once saw a quasi-auditing-program that somehow monitored software installs in order to track all changes to the system.  I don't know whether said program stayed active and monitored all of the [registry] operations performed by the installed software or not.  I also don't know what kind of performance penalty said auditing program incurred.

Sure, XML files are *supposed* to be read only, but we know developers always follow the rules.  Right?

...and then there are the people that just can't let go:

http://msmvps.com/blogs/martinzugec/archive/2006/03/01/85113.aspx

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

@fini: While it is true that POSIX system tend to clutter the system in multiple locations, the Unix world developed a way to deal with that problem, namely packages. You have a standard way of installing and uninstalling applications that you don't have to explicitely code for. As opposed to, say, .MSI installers, where you have to explicitely write the cleanup code, specially when the Registry is involved(or, god forbid, COM objects). Plus, you know where the configuration files are: either in /etc (usually for daemons and other system-wide applications) or in the user's home directory (or, in some cases, both, with the /etc being general system configuration or a configuration template). But you do know where to look for the data, and what to back up.

The issues raised here are interesting. I suppose applications can run in some or even all of those issues when dealing with configuration files. System configuration information is more likely to run into the mentioned issues. It is a matter of courtesy that Microsoft allowed, or even recommended, that applications can use the Registry machinery to store their configurations, alongside vital OS data.

The registry would be better if it had a clearer separation between "System" data and "Application" data. Anything added to the Registry should be recorded by application name and also be removed by application. Any changes to system configurations should also be recorded by application, and able to be rolled back by application.

There is absolutely no need for an application such as "SimCity 2000" to record the "Mayor Name" in the registry. Even if there were, this and all related information should be easily migrated to another PC, or removed entirely if required.

Hope this doesn't sound like a "GOTCHA!" response here, but since .Net 2.0, you can load AND save the XML application settings.

<projectname>.Properties.Settings.Default.Save();

This is for my Winforms app -- I honestly did feel hobbled in .Net 1.1 where I could load config files, but not save them.   It's like... "errr... so why don't I just go use the registry then?"

I have found the registry to be unreliable due to corruption.  Users with older machines often have a good portion of the registry corrupted.  This issue was particularly prevelant on WinME.  So much so that it forced us back to using a file that we could create a primary and backup of.

At the time I found that reading and writing from the Registry repeatedly would eventually fail.

One thing that is harder to do with .INI files is to allow sharing of configuration informations between a number of applications. And I think this should be the goal of the registry. I usualy put everything that has not to be shared in config files and the rest in Registry.

@Steven

Although you are correct that .Net 2.0 does have a Save statement. It will not overwrite your XML config file. All of your changes are stored as essentially a diff file in the users local app settings directory. So in essence the application config file is still never written to.

@Raymond: When I said "audit registry changes based on program", I meant use the program as a criterion for whether auditing happens.  I thought this would be clear by the sentence "I am fairly sure that one would have to be fairly restrictive in what is audited, to avoid performance and log size issues."  What I left out is that I'm not sure one could accomplish this "restrictiveness" by just choosing certain keys, unless by default, a program can only touch a small range of keys.  Does this make sense?

* You can get around the Unicode issue by reading/writing UTF-8 data into the INI file.

* Get/WritePrivateProfileString locks the file between access requests.  Take a look in filemon to see what I mean.  There is an Lock, Open, Read (or Write), Unlock around every call.  There should be no multithreading issues, although obviously this is a bit slow.

* Your application can (and should) cache the contents at startup time.  Just the same as you wouldn't re-parse an XML file or re-read from the registry every time you need to check whether or not some option is enabled.

* GetPrivateProfileSection is an effective way to speed up reading of an entire INI file at once, assuming you don't have a lot of 'dead' keys.

As someone who works full time in the area of Configuration Management, how you configure things matters dearly to me.

-ini files can't/didnt handle complex dependency trees or cross references.

-the registry can handle complex trees, but not xrefs

-random XML file formats do often work, but it depends on the parser, especially with corner cases like xml namespaces, illegal ascii chars, duplicate child elements, etc.

In unix, every app has its own config syntax. Xorg.conf has cross refs hacked in in one way, samba.conf does it another. Neither format can be easily 'evaluated' outside the context of the specific resolution engine built into each tool.

In windows, the registry added some things (central COM objects, admin+domain control) and took away others (ease of configure-by-file copy). To make matters worse, although most .msi installers could hand off registry config to the OS, declaring what they did, the standard installation tools tend to do their own work procedurally. this makes uninstalling harder, as the OS doesn't really know happened. This is why SystemRestore and app uninstalls are so unpredictable: nothing really knows what state change operations on the registry where intentional, which werent.

So: all formats are flawed, each differently. Once we've all got tired of XML formats with home rolled include/xref mechanisms, maybe we can move to using RDF triples and have argumentes about vocabularies and ontologies instead...

egh: In a word: No.

There's nothing really stopping you from writing your app however you want -- you don't have to use registry keys (if you want it to run from a USB key or something).  Registry entries are just the newest and most supported way of doing things.  INI files are a mess and you shouldn't use them, but don't think that you can't use them anymore.  I don't understand how people get their hackles up over the registry when the alternatives still exist (but are much, much worse).

My problem is not with the idea of a configuration database like the registry (per se), but rather the following (most of which are implementation details):

. Added transactional operations, but removed the opportunity to interact with the objects in any other way.  This ends up manifesting itself most notably as the "no easy way to migrate an application's settings between machines" problem.

. No sane user-visible tool for manipulating registry entries (unless Vista has come up with one).  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 (ie I know what I want to change, let me do so without feeling like I'm using Win3.x)

. The registry is not self-documenting.  While .ini files are all kinds of nasty, at least one could add comments in place to document what was going on.  Note that I'm not asking for every item to have help text, just an easy way to accomplish something similar to

[section]

; If foo is 1 it means thus

; If foo is 2 it means the other thing..

foo=1

(Maybe this would not have been appropriate in the early days, but certainly size and access speed are not the primary problems with the registry today)

Note all of these are my impressions as an end-user, sysadmin, and software QA guy.  It's possible that I'm missing some of the finer point of the registry.  I will say that in general, registry issues are some of the most annoying in my experience with Microsoft operating systems and applications..

Note also that I'm not suggesting that .ini files are a good solution either -- but there are systems that have solutions that are better (if not themselves perfect).  (I'm thinking of OS X on the desktop and Debian on the server).

Oh come on people.

You write a buggy app that maybe remembers its window position and the last couple of files that were open.

Put it in the registry.

To the guy who mentioned using INI files in a nested directory structure... yeah let's clog the filesystem like there's no tomorrow!  What's a little extra thrashing to fetch that window position?

I like the registry, primarily because of its efficiency both in disk usage and speed.  The problem, I think, is that there is a lot of interdependent stuff that can get buggy.  I don't see that as a registry problem though.

(addendum to the third point in the comment I wrote above, regarding "self documenting"):

I'm not suggesting that all configuration files should be, in any way, self-documenting -- just that it's natural and nice to be able to do so.  Even if machines are the primary consumers of the data, it doesn't mean that system and application designers can't make it easier for humans to interact with as well.  (Especially given that so many fixes and tuning parameters seem to involve changing the registry).

Since when were the xml files read only?  It seems like .net can leave your ~/Local Settings/Application Data/{appname}/ folders riddled with xml .config files that are written and rewritten by the app.

Re: Raymond's comments "Yes, there's a denial of service attack, tough. You didn't care about central administration anyway." -Raymond]"

Does the registry allow you to do transactions on a series of updates?  That is, can I say:

read key K -> i

i++;

write i -> K

And have this work reliably?  (And of course for larger sequences of reads and writes).

benski: Yes, the Get/WritePrivateProfileString functions lock *while they run*.  But that still leaves the race condition that Raymond described: one thread calls Get..., the second calls Get..., then both threads modify their local string and call WritePrivateProfileString back.  Now one thread's change was lost.  You need locking around the entire read-modify-write, not just each individual read and write.

Of course the registry API has the same problem...

"XML file security is not granular enough."

Why do you insist on keeping user and system-wide settings in the same configuration file. The user-config lives in an XML file in the users home directory, and the admin setting live in the system-wide configuration directory (/etc on unix).

"But since the XML configuration file is read-only, the primary objection is sidestepped."

I see no reason why it should be read-only, it's quite easy to read an XML file, modify it and write it back.

" (But if you want only administrators to have permission to read specific parts of the XML, then you're in trouble.)"

Split it in 2 files, they shouldn't be combined anyway. What if the user is roaming around the network, in the Unix-style system this is no problem, user specific settings are in the users home directory, if this is on a shared filesystem/fileserver then the user has his personal settings and preferences everywhere he logs in on the network. His home directory contains only his personal settings, system-wide settings e.g. configuration of the network or hardware, live in the local system configuration and is not shared.

How would you do this when the configuration file shares both kinds of information ?

"Since XML configuration files are read-only, you don't have to worry about multiple writers."

Again, why should they be read-only ?

"XML configuration files files can suffer a denial of service. You can still open them exclusively and lock out other processes."

Not if they live in a protected directory.  The users config is only accessible by that user (and why would he DoS himself) and the system's config is only accessible by the system (and why would the admin DoS his own system).

"XML files contain only strings. If you want to store binary data, you have to encode it somehow."

Just include the path to the binary data file in the XML. Why does everything have to live in 1 file ? That's why we have a filesystem in the first place. If you wanted one big file, you could just treat the whole drive as 1 file.

"Parsing an XML file is comparatively slow. But since they're read-only, you can safely cache the parsed result, so you only need to parse once."

The operative word being 'relatively' .

"Programs parse XML files manually, but the XML format is already locked, so you couldn't extend it anyway even if you wanted to. "

Of course you could, and why shouldn't you ? And most programs use an off-the-shelf XML parser library that can parse the file for you. Why invent the wheel twice ?

Your entire article misses the point completely. The only difference between XML (or INI files) and the registry is the on-disk storage. The big advantage of XML is that it is human-readable, which can be a real lifesaver in case of say a fatal system error.

The problem with multiple processes accessing an XML or INI file is not caused by the on-disk format, that could just af well happen with a binary file. In both cases the problem is solved by controlling the point of access to that file. The registry API functions as a single point of access to the actual binary blob on disk that is the registry. If you'd change the registry to one or more XML files on disk that were human readable, you would be able to do so without breaking a single program, the registry API hides the actual on-disk format from the applications. You'd have the same advantages as the current registry, and the advantages of a human-readable format.

The big advantage of the registry is that is provides a single point of access to the settings, but this does not depend on the on-disk format.

"To the guy who mentioned using INI files in a nested directory structure... yeah let's clog the filesystem like there's no tomorrow!"

That is what the filesystem is for. Open regedit, doesn't it kinda look like .. a directory structure ? With keys (file) which contain values (data). Yeah, let's put a different kind of filesystem inside a file in another filesystem!

"If you'd change the registry to one or more XML files on disk that were human readable, you would be able to do so without breaking a single program, the registry API hides the actual on-disk format from the applications."

You then introduce the possibility of people (or programs) introducing things into the xml file that the OS parser doesn't understand.

I find some of WinNT's system registry keys very readable.  The main problem I see is at the UI config level (e.g. the complexity of the CLSID keys), something which is independent of format, I think.

I am not against text configuration files, but I just think that a lot of apps don't really store important information to merit it, and therefore it should go into the registry.  Even according to MS, if you have more than 2kb of data to store, it should be put elsewhere.

Aaargh!:

You should try hacking registry files to see what their structure is.  Just because it looks like a filesystem in regedit doesn't make it as complex as, say NTFS.  The registry doesn't have to worry about complex cluster management.  The registry allows simpler and more efficient caching.  Do you really want the Windows file cache using a 4KB page for each INI file?

Why do you think the Send To menu isn't as responsive as the main context menu for a file?

There is a reason why databases exist in this world instead of little files scattered in a directory structure.

I've often been frustrated with the Windows Registry, but it's for a different reason than most of those listed above:  The Registry is, for all its other benefits, a proprietary solution --- a very large, well-known, and well-publicized solution, but a proprietary solution nonetheless.  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.

I've used both solutions, and I can say hands-down that I'd rather repair a broken Un*x configuration than a broken Windows configuration any day of the week.  Or, more accurately, with Un*x, I at least *can* fix things --- sometimes with Windows, you really don't have any choice but to reformat, and a lot of the blame there can be put on the inaccessibility of the piles of data in the Registry.

That said, I haven't used Vista's repair console yet --- so did anyone at Microsoft catch a clue and include a RegEdit equivalent that works off a boot CD, or is there still only an automatic repair system that rarely repairs anything and a command line that knows almost no useful commands?

"[Even if you split them that way - How would an administrator lock a user setting? -Raymond]"

He could make the file containing that setting read only for the user, but that would also mean the user can't edit other settings in the same file.

But really, he shouldn't, it's a user setting and the administrator has no business meddling with users settings.

"[And then you reintroduce the race condition. -Raymond]"

Not if there is a single point of access, say a configuration daemon.

"[A normal user can open the file for deny-write and prevent the administrator from changing settings. -Raymond]"

Only on windows, and only by design. flock() on Unix is advisory only.  If you're only reading a file and nobody is supposed to have a lock on it anyway (as with most configuration files), there is no reason to do an flock and block on that.

"[If it's a text file programs can open directly, then you have created multiple points of access again. -Raymond]"

There is always access rights, but really, why is the format of the file important ? Any file could potentially be edited directly by programs.

"You then introduce the possibility of people (or programs) introducing things into the xml file that the OS parser doesn't understand."

The same thing can be said for editing the registry with a hex editor.  You use a proper XML parser/DOM to edit the XML.

"Just because it looks like a filesystem in regedit doesn't make it as complex as, say NTFS."

Let's all switch back to FAT16, it was so nice and simple.

"The registry doesn't have to worry about complex cluster management."

No, it let's the filesystem do that for it. Just like when you store it directly in a file

"The registry allows simpler and more efficient caching.  Do you really want the Windows file cache using a 4KB page for each INI file?"

So the registry exists because the Windows file cache is inefficient ? Maybe they should have put all that effort in fixing the windows file cache then.

"Boot Windows off a CD (use WinPE) and then run regedit from the CD. -Raymond"

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 ?

[Said clue was caught years ago. Boot Windows off a CD (use WinPE) and then run regedit from the CD. -Raymond]

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, and the only resource we have is our working laptop and her Windows XP installation CD?  (Or cousin Joe.  Or grandma Mabel.  Or the neighbors down the street.  Or that guy your father golfs with every other Tuesday.  Or...)

Actually, okay, WinPE 2.0 is available to the public now (though MSFT seems loathe to admit it's available), but prior to THIS YEAR, you really did have to have a corporate Volume License to get anywhere near it:  Hence the lingering existence of a number 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?

"the administrator has no business meddling with users settings"

Come again?

@BrianK:

"Of course the registry API has the same problem..."

No it doesn't. Read the article again, threads are changing different settings.

All in all I have to say this topic seems very sensitive for many users... it certainly indicates that there is much frustration with the current system (registry)

Aaargh!:

"Let's all switch back to FAT16, it was so nice and simple."

I prefer punch cards.  The data is in a form I can visually inspect. ;-)

"No, it let's the filesystem do that for it. Just like when you store it directly in a file"

You miss the point.  The filesystem only has to worry about cluster management for a few reg hives, e.g. USER.DAT.  When you delete and create keys and data, it quite likely that the .DAT file doesn't have to change much in size, so the file system drive doesn't need to do much work.  If you start having lots of INI files, then the file system needs to manage every one of them.

"So the registry exists because the Windows file cache is inefficient ? Maybe they should have put all that effort in fixing the windows file cache then."

There is nothing wrong with the Windows cache.    The registry hives are just memory-mapped.  Need a particular integer?  Just get it.  Nothing to parse.

The point I'm trying to make is that e.g. the Start Menu and the Send To menu are not as responsive as registry-backed UI elements; for commonly used data by the system, it should be in the most efficient format, both speed wise and disk usage wise.

It is simply a waste of resources storing data in a human readable format that is primarily used by a computer program.

In reply to Bob: "There's a reason I uninstall most applications - they are garbage.  I don't want my preferences remembered when I'm chucking the software.  I would say those programs think too highly of themselves, but I doubt seriously that the programs are leaving the registry data behind for me and re-installs.  I bet 99% do it only because of the time, money, effort involved in coding the total removal."

Programs cannot and should not delete user settings when uninstalled. Per-user and per-computer data are isolated. The program only has (proper) access to the data in the account it is being uninstalled under, and the latest copy of the profile of the primary user of the application may not even be located on that machine, if it is a roaming profile.

"If you start having lots of INI files, then the file system needs to manage every one of them."

Yes, I realize that, it's kind of the function of the filesystem to do that, it's supposed to be good at it. So if the filesystem can't handle it, maybe you should improve the filesystem, that doesn't only benefit the 'registry', but also all other operations with lots of small files.

"It is simply a waste of resources storing data in a human readable format that is primarily used by a computer program."

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.

"Come again?"

the administrator has no business meddling with users settings, that's why they are called user settings.

The Registry, like COM and .doc files, is a really, really bad solution to a problem that never actually existed. It's telling that no other OS has it.

Most of the objections read like "Rain is bad, because you catch cold if you stand around in it all day." Admittedly, built in INI support isn't great, but a lot can still be done with it and writing one's own (we have Unicode, nested objects, fast and easy read/write, and encryption/digital signing for security) is more fun than wrestling with the real thing or recovering an unbootable system (especially a customer's) when *anything* goes wrong.

While we are all sharing the love with respect to the registry and INI files, one thing I find funny in regedit is that it as a "Favorites" menu.  Now, it makes sense to me to call it that, since "Favorites" has become a standard word for MS, but I just find it funny to call oft-used bookmarks to system configuration data "Favorites".  Like as if going to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion or something gives me a warm fuzzy feeling or going to HKLM\SYSTEM\CurrentControlSet feels like a big warm hug.

Around the Win95 release, Dr. Dobbs or some other magazine published an article "Why I hate the registry." I think three of the reasons listed were "It's one file." I shudder at the implication that somewhere in the world an application is accessing the registry through direct file I/O.

Hi,

I'd like to warn you that XML files are NOT read-only. Many applications store their configuration settings in XML files and allow their UI to modify them.

As examples, the FileZilla FTP client, the matching FTP server...

[Not if there is a single point of access, say a configuration daemon.]

Great idea! We could even store all the config files in one place. Each program could have a it's own config file that the daemon allows you to read from and write to.  Hmm, sounds kind of familiar. Oh, that's right, it sounds like the registry.

[So the registry exists because the Windows file cache is inefficient? Maybe they should have put all that effort in fixing the windows file cache then.]

You're right. Software like MSSQL and MySQL are obviously just making up for crappy filesystems. Database software is a waste of time, we should just optimize filesystems and use flat files.

[I'm sure that's just ducky if you're in a corporate environment and have access to a Volume License that includes WinPE.]

BartPE.

[If you want to put documentation in the registry, then go ahead and add a ValueName_Description:REG_SZ:"0 means use method X, 1 means use method Y" to all your registry values.]

Good idea! Now just to update MSDN: "KB6523907 Storing Documentation About Values in the Registry" ;)

"Programs cannot and should not delete user settings when uninstalled. Per-user and per-computer data are isolated."

The problem with Windows application installation is (and always has been) a lack of API.  Everything is done by convention: copy files here, add registry keys there, overwrite this system DLL but not this one, etc.

The problem with doing things by convention is you're stuck with it.  

What should have happened is that the Program Files directory and all the system directories should not be writable directly.  Installers should be forced through an API and then everything they do can be tracked, undone, repeated, and even remapped entirely if security rules change or Microsoft wants to rename all the directories again.  The same is true for the registry.  And when you uninstall, the operating system takes care of cleaning up the mess.  

There's nothing wrong with registry except that it's basically just another big dumb file system.  

To answer my question regarding registry transactions, it seems the answer is:

"yes, in Vista"

(would it have been so hard to write those three words?  Granted, you're allowed to be snarky in your own blog. ;-)

Whatever happened to Registry cleaning tools?  Microsoft formerly made available one, but... a few years back this appeared to have been revoked (i.e no longer publicly available).  I understand that Microsoft shipping a registry cleaning/repairing tool opens new can(s) of worms, but many third party tools do this.  So, my question: Why can't Microsoft make available (i.e. include) an improved regclean tool?  This tool could be used to clean up after piggy/bad programs  I wouldn't expect this tool to be perfect, but it would be nice to not install third party tools to clean up after other third party tools (and the circle continues).

Aaargh!:

"...that doesn't only benefit the 'registry', but also all other operations with lots of small files."

Let me put it to you this way.  Does your federal government organise garbage collection in your city, or the local council?

I don't believe in run-time optimisation.  If you know you have lots of small chucks of data, put them together and use a more efficient system to access them.  Something that is good for working with small files probably won't be good with large files.

The binary plist thing you mentioned seems like an interesting idea.  I personally thought once it would be good if there was a standard binary format that can be edited by anything.

I still don't have a problem with the registry (and I prefer it for most things), but pfiles seem okay (particularly for applications, if there is just one pfile per app).  For something like file association data and system configuration, I still prefer one big binary file.

Paul said: "The Registry, like COM and .doc files, is a really, really bad solution to a problem that never actually existed. It's telling that no other OS has it."

OS X has the similar idea of "defaults" that are stored in some random opaque location.  X11 has properties (which are stored in something vaguely like the registry in-memory).

I don't think the basic idea is bad: providing a well-defined (and now transactional), access-controlled mechanism for coordinated system configuration.  I still think that the Windows registry has a lot of cruft built in and pisses a lot of people off for reasons that could be fixed. (how hard would it be to provide a friendly registry editor?  Saying "a complete solution is impossible" isn't an excuse.  I just want something that doesn't feel like it was coded in 15 minutes as a sample program.)

Nick: "Database software is a waste of time, we should just optimize filesystems and use flat files."

It is a waste of time.  MS should just follow the popular trend and store system data in an Excel spreadsheet. ;)

"Where were you in 1983 when Windows was being designed?"

The Program Files directory was added in NT correct?  Windows 3.1 programs didn't go there.  Seems like a perfect time and place to restrict it.  Same with keeping stuff out of the Windows directory...  leave a place for old programs to mess with much but constrain new programs.

I didn't have to be there in 1983..  perhaps 1993.

I still don't really understand why programs (with the right permissions) can walk all over any critical file in the system.  Yes, sometimes you have to install a new system DLL -- but why isn't there gated access?  You can't rely on installers to not overwrite previous versions but an API could make those sort of determinations.

AlmostAlive, what do you think the Windows Installer API is?

As of Windows XP, the standard method of installing a global library does require you to go through the Windows Installer API. But the old methods still have to be supported for a while, for compatibility.

You also seem to be complaining that nothing in Windows saves you from having to specify what needs to be installed. Well, it's an operating system, not magic.

[Okay, next time somebody complains that Windows does an incomplete job, I can tell them that you said it was okay. [...]

Hurray!  Do I get stock options for this contribution??

[(Besides, end users shouldn't be mucking about in the registry any more than they should be using hex editors to edit binary files.) -Raymond]

I hope (really, really hope) that there is a hidden smiley-face in there somewhere.  

Given the number of registry edits I've had to apply to systems (as directed by MSDN articles, product manuals, or Microsoft technical support representatives), either

1) I'm not an end user or

2) there are a whole lot people who don't agree with you who work for Microsoft.

PS, I'm trying really hard to stay on-topic here.

PingBack from http://www.universityupdate.com/Technology/Firefox/5648125.aspx

Paul: "The Registry, like COM and .doc files, is a really, really bad solution to a problem that never actually existed. It's telling that no other OS has it."

I LOL'd at that.  Lumping the registry, COM and .doc files together like that.  Particularly the mention of .doc files.  So what problem did .doc files try to solve that never actually existed?  And the "no other OS has it."  LOL!  

That's all I'm saying about that.  You owe me a  new keyboard.

"All the old Windows programs that installed into, say, C:\MYPROG, would have stopped working."

Huh?  Why would that have stopped working?  You've got a whole Windows 3.1 API stuffed into XP.  Lets 16bit applications screw with 16bit DLL's just like they always had and make 32bit applications play by a better set of rules.  Eventually, you phase out compatibility with the old applications (like you have with 64bit Windows).

"Or if you want to have two sets of rules"

You already have two sets of rules, Win16 and Win32.  I don't get the argument that you have to play by the same rules as 1983 when you've had lots of opportunities to change them.  

"AlmostAlive, what do you think the Windows Installer API is?"

Gazpacho: Actually, I was going to bring up MSI.  And yes, it does about half of what I mentioned well but you still can uninstall all the setting from all the users when you remove an application.  It doesn't dig deep enough.  And it still allows apps to trample all over the file system and the registry.  And Raymond has a point, now that the gates are open you can't have two sets of rules.  It's too late for MSI to be truly effective.

"You also seem to be complaining that nothing in Windows saves you from having to specify what needs to be installed."

Actually, what I'm saying is nothing in Windows forced you to specify what is being installed.  It's just a random bunch of files and registry keys.  An API would have allowed Windows to understand what is being done to alter it, undo it, maybe even replicate it.

I have a kind of love-hate relationship to the registry. In some ways it works quite well, mostly at the presenting a uniform and safe interface to configuration data, but my main problem is still the identifying and perhaps migrating data for a specific application.

One possible solution (which might even be possible to implement without breaking the existing API) would be to support a kind of overlays stored in separate files. For example, an application calls an API to get a token for its overlay. The overlay data are visible to all applications, and changing any data in the overlaid data changes it in the specific file that stores the overlay, but newly created keys would belong to a specific overlay, or the regular (current) registry.

One way the overlay tokens could perhaps be implemented was through a new API for creating HKEY tokens.

An overlay could then (somehow) be unloaded from the system and perhaps be moved somewhere else.

An overlay would then be either machine specific or user specific. (Machine specific ones would probably go in the All Users homedir.)

"The administrator has no business meddling with users settings"

Maybe if we say it often enough, it'll become true...

"You've got a whole Windows 3.1 API stuffed into XP.  Lets 16bit applications screw with 16bit DLL's just like they always had and make 32bit applications play by a better set of rules.  Eventually, you phase out compatibility with the old applications"

If you did that, nobody would have written 32-bit programs and then you wouldn't be ABLE to phase anything out...

Dean you're saying that nobody would haved developed for a new API?  I guess Microsoft should never have created .NET -- doomed to failure.  

Developers like well designed and useful APIs and languages and they'll go out of there way to use them -- sometimes when it isn't even practical.

As has been opined by many in these comments, every storage implementation has it's pros and cons.

The problem was that INI's were declared persona non grata and The Registry feted as the solution to all the problems associated with INI files.

Which was fine as far as that went....  and as long as you are happy to embrace the problems that THE REGISTRY brought to the party.

If The Registry had been presented as just one new option IN ADDITION to INI files then developers could have chosen the mechanism most appropriate to their needs (often perhaps varying even within a single application) and even if not everyone was happy, I guess a lot more people would have been.

Of course, nobody was ever FORCED to stop using INI files, but their official deprecation was effectively a public tar and feathering for any application so outmoded as tobe seen to continue using them.

XML files took the stigma off of INI files by giving them a sexy NEW name and a "modern" look and feel. (i.e. bloated, cluttered, verbose and with just a bit of a whiff of HTML - that sexy new web tech so it must be "cool")

It was possible, with very little effort, to get just as much structure in an INI file as is present in many XML files and often with far more clarity.

Had the INI API been maintained and extended, who knows what we might have today.

I have to admit that I prefer INI to registry most of the time. Many of the apps I work on don't need to share config data, or special security measures, or concurrency checks - in other words they just need a SimpleConfiguration API. Yes, I know this sounds very much like INI files API. I like the ease of migration (xcopy) that comes w/ some .net apps but unfortunately it's easy to ref an assembly or DLL that requires COM and now the Simple API can't be used. In the end this just means more job security so I guess I can't complain too much...

"It's all about the value proposition. 'Hey, here's a new API. The new one is more restrictive. You can't do as much with the new API as the old one.' That's not going to win over many people."

I disagree.  The old way is not really to have an API at all.  Just copy files around and add registry keys.  An API would be easier to use and safer.  That's the value proposition.

And I suspect many developers would choose a slightly more restrictive API over DLL hell and registry bloat.

The registry doesn't have enough segregation. Any program can party on (most) any part of it, including other programs settings. So when you want to do something to ONE program and ONE alone, it becomes a wild goose hunt to find all of that programs settings. That is my opinion, and judging from the comments it seems many people share it.

[XML files took the stigma off of INI files by giving them a sexy NEW name and a "modern" look and feel. (i.e. bloated, cluttered, verbose and with just a bit of a whiff of HTML - that sexy new web tech so it must be "cool")]

So what you're saying that XML files are "INI 2.0".  Brillant! :)

"The registry is not self-documenting.  While .ini files are all kinds of nasty, at least one could add comments in place to document what was going on."

That's a good thing.  It forces documentation (if it exists at all, which is by no means guaranteed either way) to exist elsewhere -- such as on a website that can be updated if it turns out there's a mistake or misleading wording.

"A normal user can open the file for deny-write and prevent the administrator from changing settings. -Raymond"

But administrators can break the lock and modify the file anyway, if they really want to.  Admittedly I don't think Windows provides an easy mechanism out of the box to do this, but I'm sure it's possible.

"Actually, okay, WinPE 2.0 is available to the public now"

It is?  Hey, it is!  Cool, I've been wanting to get my hands on that for a while now.  Even if it is only for Vista.

"It's all about the value proposition. "Hey, here's a new API. The new one is more restrictive. You can't do as much with the new API as the old one." That's not going to win over many people. -Raymond"

I've seen this exact effect with some of Vista's changes, actually (mostly UAC, with apps running LUA by default).  I hang around in a forum for software installers, and it seems like every few days someone starts a thread along the lines of "how do I detect Vista so I can make it install into My Documents (or similar) instead of Program Files, since that doesn't work".  Then it takes several days of explaining that they shouldn't be doing that, and in the end it's hard to tell whether they finally got the right idea or whether they're just stumbling ahead anyway.  Sigh.

I'm not entirely sure how I feel about the Registry one way or the other, and I tend to use both registry settings and XML config files (which *are* writable by the app!).  The files are more useful when targetting an app-on-USB-drive scenario, and they're more accessible for user tweaking (although only slightly, since if they're not actually on the USB drive then they're off in a hidden folder in the user profile, which isn't as useful).  And I've never been comfortable with having all the settings in one place where it can get munched by a rogue program or bad sector.  But it does provide a nice and fairly uniform way to find things (such as locating where an app is installed in the first place), and as Raymond said it's better with multi-app crosstalk.

[I disagree.  The old way is not really to have an API at all.  Just copy files around and add registry keys.  An API would be easier to use and safer.  That's the value proposition.

And I suspect many developers would choose a slightly more restrictive API over DLL hell and registry bloat.]

Ah! So you live in a parallel universe where applications like <non-Microsoft web media player developed in Seattle> didn't stomp all over every user setting you can think of and violate every rule of "good software" there is? I wish I lived in the same universe you do.

Unfortunately, Microsoft learned long ago that you can't trust developers to do the right thing. Guess how long it took <IBM-owned email client that competes with Outlook> to properly support multiple users? I'll give you a hint: It wasn't NT4, and it wasn't Windows 2000, and it was at least a decade later than it should have been.

I love the fact that there's the Registry and it's somewhat popular, though I never use it.

Because it's one more feature I can list for my applications: "Does not use Windows registry"...