Why oh why oh why didn’t I listen–I just fricked around with my registry.
I know better.
(I borrowed your image above–I should have it pasted to my forehead.)
My idea of how to fix the registry problems:
Like David E. said there are basically three types of settings:
System
Application
User
System settings are what the registry should be used for.
Each app will include a file to regenerate its system settings.
To handle application settings:
There should be a folder (something like ProgramSettings) every application will get a folder inside of it (the only one they can read from in that folder). Inside that folder each app will get a database file (and there will be a standard api for using it) this will be faster than xml and average users won’t know how to read it.
To handle user settings:
Every user will get a My Settings folder (like someone else said) they will get another database in here (once again programs can only access their own files)
Then to copy programs you would only need one (or two) folders, and applications could automatically generate new ones if you forgot one.
And because the registry is still there for system settings it would be fully compatible with current programs.
Just an idea
fully agree
The Windows registry is a very very bad idea!, it’s full of garbage left there by the apps.
All apps should use configuration files (.ini) and use the registry only when there are no other options (for example, to assign file association).
The registry is like inheritance. There are ways that it can be used responsibly, but it’s very design encourages misuse. If I recall, .ini files were the same way.
I always have thought that the registry was (and still is) a bad idea.
Remember reading somewhere that this approach was taken because COM was not thread-safe at the time and it couldn’t handle more than one instance of a dll in memory. The registry was a place to ensure that not to happen.
o melhor programa amador que ja vi
I have a suggestion. Get Microsoft to change the name from Registry to Library(ies) and creat a Librarian(s) to work the Library(ies). Programs submit there requests to the Librarian(s) and the Librarian(s) provides services like deciding were to put the data and retrieving the data to pass back to the program when needed. Then there is the DLLibrarian to take care of the DLLibrary(ies). The Librarian assigns Program/user ID's (ssn, tax ID, with PIN for security) and catalogs the data using an identification system (alphameric,Dewey, Library of Contress, Wal-Mart bar codes...?) and when the Program needs to move, one of the Librarians can gather All the data, package it in a box (zip file?) for shipping to another Peee Ceee.
Just an Idea!
Late addition to the thread (2 years late!):
Defenders of the Registry offer the common theme: The problem is not the Registry, it’s poorly behaved apps adding junk to the Registry. But that’s exactly the problem. By making one common place where applications are supposed to put all sorts of data, the Reigstry is inherently full of junk. One poorly-behaved app can trash it up. One poorly-behaved app that fails to clean up after itself when uninstalled can trash the Registry forever. And as it can be very difficult to figure out what app put what where and why, even a very knowledgable and experienced user can find it virtually impossible to clean up the registry.
Here’s how I think it should have been done: Microsoft should have created one file where an application registers it’s name and the path where it is located, and the list of file extensions that it supports. Period. Do not provide any way to express any other sort of configuration data. Require the application to store any other configuration data in its own directory. The system Uninstall function can then delete the application entry, the associated extension entries, and that directory. There is no need to even have such a thing as an uninstall program.
Then it doesn’t matter if a poorly-behaved app creates a lot of junk. If you no longer need an app, uninstall it. Then it and all its associated data are gone.
If you wish you can provide tools to create a configuration file in a standard format, like an INI file. If an app uses this format and these tools, fine. If not, it doesn’t bother anybody else. If an app has unusually complex configuration requirements, that’s its own problem, and no one else’s.
Comments that the Registry simplifies pushing common configuration data across an enterprise strike me as unconvincing. There’s no way an organization can push common configuration data for unknown applications. All you can do is say that you’ll push configuration data for specific, known applications. So fine. If each application has its own configuration file, then you just say, here’s our standard configuration for MS Word and here’s out standard configuration for Jim Bob 2000. You create those configuration files and you push them out to the appropriate directories. If an app splits its configuration across 200 files with indecipherable formats, okay, you’ll have trouble pushing that. But if an app splits its configuration across 2000 Registry keys with indecipherable names and formats, how are you going to push that? Don’t tell me you’re pushing the entire Registry.
The Registry is fast? I don’t see how that was true even in 1995. Loading an app means loading an .exe file and often many other files. Even a small app is probably a few hundred kB, big ones are often megabytes. To say that in addition you have to read a configuration file that is probably a couple of kB, surely makes little percentage difference to the total load time. Okay, a complex app might have a complex configuration, so now the load is 10k or 20k. But an app with a 20k config file surely has multi-megabytes of code, probably spread across numerous EXEs and DLLs and whatever, so it’s still a small percentage difference.
So I agree: The Registry sucks. Throw it away.
I think the registry is a good idea but only if not used extensively. I’ve been working a lot with Wordpress (a blog engine) which has a central regsitry database in MYSQL and that works very well because it’s structured and able to deal with all the different things that can be done with it.
I can’t see why people keep blaming MS for bad practice people adopt.
Who said you can’t use ini files? In fact, anyone reading MS’s WinAPI Bible would find a section which suggests when and which method a programmer should use to store information.
Secondly, for your information, MS published both INI and Registry writing APIs.
So next time you want to blame the registry chaos, rant about program’s improper use of registry (such as Firefox’s/Mozilla NPAPI deprecated/underused registry settings).
Kind regards.
Just type “Windows Registry” in google…
All you find is registry cleaners, registry repair tools, demystifying the registry, registry tweaks and fixes, registry recovery, how to backup the registry…
Now come and tell me this is not a piece of junk!
fiddling too much with the registry without the appropriate knowledge can mess up your PC big-time
fiddling too much with the registry without the appropriate knowledge can mess up your PC big-time
The registry sucks big time. When Unix was created long time ago (with 5MB hard disc), they chose to store config files as text files. The reason is that over the years, only text files will still be readable. Binary config files sucks. In Unix you start up an editor and edit the config file. In Windows you need a reqistry repair, otherwise you are screwed. You have to reinstall Windows. In Unix, you never reinstall. You just fire up an editor and repair the problem.
Can you spot and correct the error in this text config file?
Xscreen 1600
Yscreen 120"#¤%DS+
Bitmap 24
Mouse Yes
Or this error in this binary file?
0101110101110101101110111101010001010100110101
Which is more transparent, and more human intuitive? Binary formats need special editors. In 30 years, the binary format will be obsolete, but the text file will not.
“Those who do not understand Unix are condemned to reinvent it, poorly.”
– Henry Spencer (http://en.wikiquote.org/wiki/Henry_Spencer)
We’ve just begun converting our programs back to INI files for most settings.
Things like window position, column widths, crap that the user can drag around or sticky settings while the application is running. That we store in the registry.
Important stuff, back into the INI files.
I think the registry is good for precisely one thing: File Type Associations. Having a central place, where each extension is connected to one or more apps is loads better than the shebang method on *nix (although I think it would be best to support both). Configuration files are going to be a mess no matter what you do. Sticking everything in one spot is just idiotic. One place for all apps in your office suite? Sure. One for all apps in your system? No thanks.
Never could bring myself to touch the registry while I’ve coded. When I decided to store app settings somewhere, some nice folks on Channel9 helped me to see that I could export an AppSettings class as XML to the \All Users\AppData\My App\ folder. This has allowed basic users to tweak stuff if they made a change that went against the settings. (Which, if coded correctly, should never break your program.)
Microsoft’s main reason for introducing for the registry was not the stated ones. I believe it was intended to make applications dependent on a verified install process. I.e. to prevent simple copying of application directories as a means of installation - copy protection through obscurity.