The Windows Registry has been a computer administrator’s nemesis since about the time it was invented. It started with good intentions, but turned into a cryptic, haphazard mess. Its like a kitchen sink with a broken garbage disposal.
One of my biggest gripes about Windows is that you can’t re-install the OS without replacing all the applications. Have you ever been reluctant to reinstall because you knew that as soon as you do all your applications will be broken and need to be reinstalled too? Why is this? Shouldn’t you be able to reinstall the OS without breaking the apps? Unfortunately, the registry is owned by the OS, and because of this coupling, you can’t.
Its fixable – search
The good news is that this is fixable. The registry just needs to be rewritten. Today, the “registry” is a centralized index of attributes from every app installed on the system. What if, instead, the registry was a set of small files that resided on disk, each file contained a small set of attributes that are related somehow, and we maintained a search index to find things through all of these files automatically. Each application would have it’s own “.reg” file(s), which could reside with the application. If you move the application to another location on disk, its registry file would move with it. If you delete an application, its registry file would be deleted with it. Make sense? Now, we’d maintain a central index which would seek out these special filesystem files and index the data. You could still run a virtual “regedit” application, and it would look identical to how it looks today. Its just that instead of a central storage mechanism, it would use a distributed storage mechanism.
Benefits:
1) Containment of registry settings. Today, if you look at the registry, you might be able to guess where a given registry setting came from, but you can never be sure who really owns it, if it is still relevant, or if there is harm in deleting it. With this new model, where .reg files reside side-by-side with the application, its inherently obvious where the setting came from.
2) Ability to migrate the registry with the application. Today, if you want to move an app from drive C to drive D, you probably have to reinstall. There are other factors too, but one obstacle is the fact that the registry settings have to change, and you have no idea where they are. Adding a few variable substitutions to the registry files for things like (%MYPATH%), and you can now move apps and their registry settings by just doing a filesystem copy. You can now actually backup your apps.
3) Simpler Security. Security of the registry would now be handled by filesystem protections. IT folks could set the registry settings that they want, and use filesystem protections to make sure they can’t be modified.
4) Conflict Resolution. What happens today when application A wants a registry setting to one value and application B wants another? Well, you pick one and lose the other. In the new model, you still have two values, and you’ll need a rule to determine which takes “precidence”. But, if you open up regedit, it will be able to tell you not only which items have conflicts, but where the conflicts are, and what the conflicting values are! Now, you’ll be able to pick the right setting with knowledge about why there was a conflict, rather than having to debug an obscure problem that you didn’t even know about.
What do you think?
Example:
-
/Documents and Settings/
-
UserBob
-
Application Settings
-
Microsoft
-
Word
-
word-usersettings.reg — word might chose to store some registry settings here so that they can be written by a non-admin user
Intuit
-
Quicken
-
quicken.reg — quicken might choose to store registry settings here
/Program Files/
-
/Quicken/
-
[application files go here]
quicken.reg — This file contains all the quicken registry settings
/Microsoft Office
-
[application files go here]
office.reg — This file contains all the office registry settings