I agree. The registry is obsolete and should be completely replaced.

Well Duh, the registry sucks.

I love Mac OS X's system of plist domains [User, Computer, and the little-used Network] along with MAC-address-tied ByHost plists in each for truly machine-specific settings (Power and Networking, mainly).

Applications can be run from anywhere, but generally can't write to /Library (using ~/Library instead) unless they're in the Applications folder.

Couldn't agree more! In fact, all applications I write use INI-files and not the registry. This is in part because I don't want to clutter my own (or other peoples) registry with application-specific "junk", but also because this way I can copy my application to another computer and still keep all my settings. Couldn't be easier!

Still, I remember back in the good ol' days when I spent time "cleaning" my sys.ini and win.ini files. They weren't all that pretty either :-)

Since the registry API can be re-mapped to anything (e.g. a pile of discrete hives instead of one big clusterfsck), another possibility is to remap an access to HKLM/.../$APP_NAME into one that modifies /Program Files/$APP_NAME/Configuration/app_hive.dat. Admittedly this is a huge simplification (keying off $APP_NAME would require a fair bit of trickery to get right), but I think unbundling the registry would be the single biggest improvement you could make.

Chalk me up as another one who agrees with you on this. As a matter of fact one of my first podcasts I did this was part of the subject (1:50). My point was that the mistake made was letting everyone and their brother have access to from what I understand was originally suppose to be the private playground of Windows alone.

http://www.winextra.com/2007/08/16/off-the-cuff-dont-always-blame-microsoft/

Not a single positive? Like the registry being hundreds of times faster? (This is mainly an issue with MFC apps that like to write out their full settings every time you change one; this leads to painful performance drops in apps like MPC with .ini writing on.) Or enabling hierarchical storage without custom parsing? (XML config files fulfill this need now, but they're tortuously slow for some applications. Not as big a deal as back in the NT 3 days.) And how do you implement organizational policy across random files in random formats, without a standard API, short of enforcing every single setting? Heck, I even use group policy for home use, as it's simpler and more resistant to reversion than direct editing.

Would you really expect more than a few badly-behaved apps to really be that much better with ini files? You can throw your settings anywhere on the system just as quickly as you can put them anywhere in the registry, and I've seen it done many times. Many applications totally mess up the local/roaming, and want to put settings in hidden folders right in your home file, if they even bother with anything but machine settings. Installers are total junk, strewing important files all over, and up until the MSI switch most were still 16-bit! (MSI is worse, since you can be boned trying to remove something by not having the original media available, regardless of registry locations.) Macs have the right idea, with their monolithic folders, but many third-party apps still put per-user settings right in the shared program folder.

The second most common problem with moving files - com servers - can be easily fixed by just reregistering everything in the folder after moving. (for %A in (*.dll;*.exe) do regsvr32 /s %A) You need to modify it a bit on 64-bit OSes though.

I'll grant binary and opaque, although there are ways to read it in *nix now. All performant databases are that way, though.

I would have liked to see the registry split into more files than the big 5 keys, such as one file per subkey of HK*/SOFTWARE, and of course the win9x registries could've been more bulletproof, but that's the only major issue I have with it.

"I can't find any new Windows filesystem convention for system level, non-user-specific settings."

C:\ProgramData\Vendor\Application

(or CSIDL_COMMON_APPDATA)

"they could elect to follow the new, much saner Windows Vista conventions for storing application-specific data"

Weren't they Windows XP conventions already?

> they could elect to follow the new, much saner Windows Vista conventions for storing application-specific data:

Er Jeff is it me or there's absolutely nothing new about that?

I mean on my 2K and Windows boxes i already have a %APPDATA% envvar leading to `%HOME%\Application Data` (which admittedly sucks since it has a space in it, on the other hand by default user accounts are in `%SYSTEMDRIVE\Documents and Settings` so it's a minor issue) and quite a few software (most notably any Mozilla soft, the latest Winamp versions if you check "1 profile per user" and a few others) already store their userconf data there.

Some (adobe for example, I think) store stuff in both %APPDATA% and the registry, but that's a slightly different issue.

Anyway storing application-specific per-user settings and data in files is already very easy to do and standardized (if you know what you're doing) since 2K.

Was The Windows Registry a Good Idea? No

Was it better than the implementation of INI files? Yes

Solution : A better implementation of ini files

The two things it solved was speed and centralisation
Ini files are slow, but don't need to be?
Ini files are scattered but don't need to be

If I run a program I would expect it to save my settings in my space not in it's program folder, not in the system folder, not hidden somewhere (seemingly randomly) in the registry, if it's a global setting - isn't that what All Users is for?

Aren't there Windows API calls that can manipulate .INI files in the same way one can manipulate registry keys?

I feel your pain, I have spent many a dark day trawling through the regestery for the holly grail that is a working application...and usualy find is a Shrubbery and someone shouting Ni! Ni!

As you can see, sanity is actualy a hinderence for registery manipulation...

you're only just starting to wonder?!

you're only just starting to wonder?!

The registry is a terrible thing. I never used it for programms I wrote. I like to store all my application configuration in a xml file. That even allows me to make changes with a texteditor while I am at a customers pc.

The registry just plain sucks.

Windows is filled with hundreds of examples where junior programmers reinvented a wheel already rolling in *n*x, and did it wrong. They may be smart, but they are not experienced, and they ignore the outside world. Over time this problem has become worse, and Windows has become dumber and less compatible.

The registry is like communism, a great idea in theory, a horrible idea in practice.

One of the worst things that the registry begot was the COM registration system. The quagmire of GUID keys and convoluted registration schemes could only have thrived in the dank unseen place known as the registry. Of course they realized too late that it was horrible and their half-hearted attempt to fix it with side-by-side COM registration (read registry-free COM registration for true xcopy deploys) was almost as full of issues as the problem it was trying to solve.

I've stayed as far away from the registry as possible for the last few years and it's amazing how many installation and application issues go away once you do. These days I use anything from INI, XML, YAML and even JSON to store settings and they are all much more usable than the registry ever was.

I hear a lot of what Foxyshadis above is saying but I disagree with the issues of settings file speed and com servers moving being "easily fixed" by just re-registering. As someone that disliked the registry early on I used a custom file format that was probably closest to what YAML is today and it came pretty close to being as quick as the registry. Secondly I've also done enough COM development to have the scars and in any deployment besides the most trivial simply re-registering COM servers is rarely simple. If you're lucky the worst will be that the uninstaller gets confused and leaves a few dozen stray keys, at the other end I've seen entire suites of applications from different vendors brought to their knees because someone from IT moved an application from one share to another and did a blanket regsvr32 in the new folder.

I will agree with him though on the fact nothing can rescue bad application design. Whether a bad app abuses the registry or the filesystem it's still being abusive. Poor developers expect their tools to make their work look skillful while good developers use their skill to pick the right tools. In this case the registry is rarely the right tool.

To Andy: The APIs are ReadPrivateProfileString and WritePrivateProfileString. Their documentation comes with a warning not to use them. I've read that they are not thread-safe amongst other problems.

Is there anything that can be done about it or do we need to complain harder first is what I'm wondering?

Wouldn't the problems all go away, if people don't store paths inside the registry?

install Linux mate! or if you wanna candies go for Mac Os/X :-PPPP

I think the reason that /etc is not as hellish to work with is that it uses the same namespace management and plaintext manipulation skills and conventions the many people are familiar with for other applications. If the registry had better tools and conventions then it could work just as well.

@ beza1e1 : I think the problem is that once the paths have gone *poof* from the registry they generally don't assume any kind of "sane default".

You'd not only have to make that practice go away but all the books recommending it, too. Time for a bonfire? ;)

@ Sander: complaining won't work since this is one of those nice things that regular customers solve with a format/reinstall or more correctly, "call the kid from next door to clean up my Windows". Besides, stepping away from it will again result in backwards compatibility, unless you have some nice catching mechanism for installers that grabs every value written to the registry and emulates it back again when an application asks for it.

.Net apps seem to be going the right way with their .config files. (unless these are for something else and I'm misinformed).

I was forced to search through the registry with Regedit a couple of times. It's appalingly slow. Later, I had to do the same in Wine. I couldn't believe how fast it was. Out of pure curiosity, I checked how Wine stores its (emulated) registry.

...

Can you guess?

...

In a bunch of .ini files!

The registry fails us because it breaks the cardinal rule about localizing changes to known places.

However, program settings are not the problem. It's the registration of the COM servers that prevents most apps from being able to be run off a USB key. I'm not sure if there's a simple answer to that one though.

On an offtopic note, did something change in your font rendering? im using Firefox and its quite hard to read.

I love the Windows Registry!... Just kidding. I guess it does its job, despite not being an optimal solution.

I've actually once managed to break .exe file association using regedit... fixing that was real fun.

I personally like XML and ini configuration files, but they should be kept in the dir with the rest of the application's files IMO. Why does everyone want to put a memento of themselves to my Windows dir?

"Those who do not understand Unix are condemned to reinvent it, poorly."

-- Henry Spencer (http://en.wikiquote.org/wiki/Henry_Spencer)

From the DUH department:

Mr. Atwood has apparently run out of things to blog about.

Yep, go with those ini files (or xml)!

Then deal with the performance hit of searching out keys or trying to update values. Don't forget to implement proper locking logic to handle multiple users hitting the same ini file.

Doesn't anyone remember why ini files were deprecated?

XML can have comments, blah blah. Sorry, there are lots of partial implementations of XML out there. You may just break your application by putting in comments.

Grow a brain and think it over.

I'm sorry, but your stance on the registry strikes me as that of a Luddite.

First of all, the registry materialized in 1993 with NT 3.1. Win95 had a scaled down version of the registry, sans security, sans decent file system, etc... That you mention Win95 at all seems to be a calculated way of making the registry look especially bad and unreliable.

Secondly, a bunch of ini files scattered around the drive is not the solution to any problem I know of. A bunch of ini files stored in the Windows directory is not the solution either.

Storing setup information hierarchically makes sense. Specially when you happen to install more than one app from some of the larger vendors. (MS Office stores stuff under HKLM\Software\Microsoft, all Adobe products presumably end up under HKLM\Software\Adobe -- all very neat -- per user storage ends up under HKCU)

Yeah... Where does your ini files go for the per-user settings? %userprofile% directory? Messy. That is the way Win 3.1 did things. That is exactly what most of us wanted to avoid.

"The registry has to be in sync with the filesystem. Delete an application without "uninstalling" it and you're left with stale registry cruft". Uhm, yeah? It has nothing to do with the filesystem. If the uninstaller doesn't clean up after the application, then it does not matter where it stores its settings. You're not going to find them any easier if they're not stored in the registry. Au contraire. (on a side note: Do you really want to lose personal settings when re-installing an application, if you ever faced having to do such a thing? MSI has reduced the need for re-installations a lot, but not completely eliminated it when faced with broken install scripts)

Finally, it is not the fault of the registry that YOU install "every rinky-dink application on the planet". Clue: Don't install every rinky-dink app. At least not when you are running as administrator. Because then you will require every rinky-dink anti-spyware, anti-virus and personal firewall application there is, which will further molest your registry.

--
Rune

I once saw a program on one of the odd high-number channels, where they interviewed this guy at Microsoft. Turns out he was on the team that originally invented the registry. They showed him giving a powerpoint demo and the first slide was something like

About the registry:

sorry, sorry, sorry, sorry, sorry, sorry, sorry, sorry!

I'm sorry, I left off this gem:
"The registry is a single point of failure."

If you have a bunch of configuration files in a directory somewhere, and you delete those files... Isn't that a single point of failure?

The registry OTOH is automatically backed up. In every version of NT, it has always been possible to boot using the "Last good known" configuration.

Yes, there is a warning in most KB articles. This is because regular users (who have no business editing e.g. .ini files, let alone the registry or God forbid xml files!) sometimes stumble across these articles.

"Let's say you wanted to move an application to a different path on your machine, or even to a different machine altogether." I have done this several times. Not an issue if you know what you're doing. (You can load another registry hive temporarily, or you can connect to a remote machine's registry)

Your point about the lacking comments is valid.

--
Rune

at first i thought that windows registry is a good idea. That was before my pc is cracked by spywares.

ok.. enough of that.. The only good thing i see at the registry is the managements of defaults.. default is good, i think..

other than that it's plain crap..

The biggest problem are all those broken apps that scatter their settings across the whole system but change the storage mechanism for configuration settings will not automagically any broken application. So in reality it’s not the registry that is broken -you are complaining about broken Windows application. A brain dead programmer will make any storage system a “trash heap of miscellaneous junk settings”.

“Manipulating the filesystem is utterly obvious, completely intuitive”

Only for us experts/computer gods. For the average user manipulating the file system is very difficult, the biggest problem are folders. These are neither obvious nor intuitive.

“You have to reconcile almost everything you do in the file system with that opaque, unforgiving binary blob of data known as the Windows Registry.”

Look at Unix: You have to reconcile almost everything you do in various files scattered across various folders (/etc/..., /usr/…, /var/…, /opt/…, /home/…) in various different formats. sendmail.cf vs tnsnames.ora vs smb.conf vs httpd.conf – such fun!!

“For instance, when I upgrade and reinstall Windows, most of the games I have installed on my secondary drive are instantly broken because they store cd-key…”

Plus filter drivers for their copy protection, and PunkBuster, and more. Most modern games generate unique machine ids during install and there you will never be able to simply copy them – this is by design and independent form the storage mechanism

“the new, much saner Windows Vista conventions”

These conventions are the same as the Windows NT 4.0 conventions, btw :-)

“can't find any new Windows filesystem convention for system level, non-user-specific settings”

% ALLUSERSPROFILE% ?

“single point of failure”

INI files are a “single point of failure” (at least for the application, editing system wide plain text config files can break your computer in a similar way) so you should make backup copies of those files as well. There is a German saying:
Beginne Deine Arbeit nie
Ohne Sicherheitskopie”

„Never start your work without a backup copy”

“XML config files are reasonably human-readable, and they allow as many comments as you see fit”

Only for us experts/computer gods. The average user will have no clue and it’s very easy to break an xml file – a missing / and the whole file is useless. INI files are much more robust.

“in sync with the filesystem”
This is true for any mechanism. Only settings stored in the program folder are deleted but what about start menu entries, shell extension registration (file type handlers for double clicking), etc ? You will need an uninstaller to remove these settings and a poorly written uninstaller will stay a poorly written uninstaller no matter where the settings are stored.

“The registry is monolithic … Good luck extracting the relevant settings for that one particular application”

Look at Unix: Good luck extracting the relevant settings for that one particular application from various config files scattered across the whole file system with various formats (some plain text some not)

“What's depressing about all of this is how prescient the UNIX conventions are in retrospect”

Unix is even more broken than Windows but there are less broken public Unix applications.

It’s not Windows or the Registry that are broken. The main problem are the great many broken Windows application done by brain dead programmers. And there is no technical solution for this.

As others have pointed out, .INI files have their issues to (inconsistent format, can be scattered around, multi-threaded access), but *nix has made it work relatively well. That said, I pity the fool who has to look at sendmail.cf for the first time.

But why not replace the registry with the obvious? A database. MSDE is small and light, provides central access, is way faster than any of the other technologies, has great APIs and has plenty of tools for management.

I'm always amazed that Microsoft fails to use one of its best technologies (SQL engine) for other products (registry, desktop search index, Exchange information store, ...)

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.

Funny also that no one is mentioning the use of .Net app config files (whatever.exe.config) which are simply XML files with application settings in them, but in a standard format.

Does that mean no one is really doing .Not^H^Het development?

I hate the registry as much as the next guy but one positive that comes out of it is the ability for one application to check to see if another application is installed (what version etc..) Also as annoying as it may be the registry in many cases is a huge anti-piracy tool.

Sheesh said:

> Don't forget to implement proper locking logic to handle multiple users hitting the same ini file.

Under what usage scenario do you have multiple users changing the same setting at the same time (and thereby requiring locking)? And if it does, what the hell is wrong with standard file system locking?

You have a server, you have multiple users with personal settings and/or state to maintain - why should they "hit the same file"? Shouldn't any sane application provide each user with their own settings file in the their own home directory?

Or do you really suggest that your preference for a bright yellow desktop should override mine (and all other users) preference for the standard sky blue?

Seriously, is there _any_ situation where conflicting updates to settings file is a problem? Do you really have multiple administrators performing uncoordinated configuration changes on a single box at the same time?

> Grow a brain and think it over.

I've already got one thanks.

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.

Ryan, good point but that would also be possible if the registry was used for nothing more by applications than to write the location to their "ini" file.

As for those saying ini files are bad because they are scattered around... I'm not sure what your complaint is. Do you believe my jedi knight 2 key mappings really need to be saved in the same spot as my microsoft word settings?

Using the registry means that you're updating global machine state to install your application. Sometimes this is exactly what you need, but more often it is nothing like what you need. Accessing global state has all kinds of unpleasant implications on user ability to have multiple versions of your app/library installed, it is a substantial downside that needs to be balanced by a corresponding upside to be worthwhile. Such upsides are very rare in practice.

I've written libraries that get used by dozens of in-house projects at once (analytics for banks), and the first key idea of such libraries is xcopy-type install, otherwise you are absolutely and completely hosed - how else can you have several versions running on a single machine, used by applications developed by competely independent teams? While the registry is a reasonable match in some cases, it is hopelessly overused in the Windows world.

A sensible default posture is to request uses of the registry to be positively justified, rather than taking it as a starting assumption.

I remember many many years ago, back in the days of Windows 3.1/3.11, Microsoft told developers to contain all of their application files in one directory. This was at a time when application INI files were starting to clutter the win.ini and the system.ini. The Microsoft fix was to have the application INI files located with the application and not in the OS INIs. Seems to me that would have worked

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.)

Your article reminded me of this quote;-

Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer

nuff said.

Actually the problem is that MS has never written any useful tools for the registry. The null problem wouldn't be a problem if we had a decent registry editor and useful command line utilities (possibly Powershell??) I won't list the other commands that are missing, I leave those to your imagination.

But I can't close this message without mentioning the almost complete lack of documentation, and what I think are implementation problems, mostly a lack of date stamping for entries but also the way the same information is stored in multiple places, and the decision to show, what is it, three generations of some registery information (current control set, and all it's little brothers) in the program they call an editor.

It may not be all it should be, but if MS would get of its collective backside and provide the tools it could be very much better than it is.

Ever tried to make a single entry in an ini-file readonly for the user?
I wish you lots of fun...

Only with the registry you could administer hundreds of machines in an easy and consistent way.
Only with the registry there is a way to double-click a .reg-file and enter its content automatic into the registry.
and on an on and on.
Registry is like a database, ini-files are like chaos.

Thats awesome, Windows is becoming more like Unix with every release and I'm all for it. I do wish they'd adopt the same plist configuration format found in OSX, its XML based, very flexible and easy to work with.

Ini is kinda primitive when compared to plist, and Unix's convention of having no convention here is a poor idea.

All in all a good move by Microsoft.

Don't you think that .NET's move to .config files proves your point without even making it? Hell, the .NET libraries for manipulating the registry aren't even in the System namespace. They're hidden away in the Microsoft namespace, where only desperate people and VB programmers go.

I think Microsoft wants the registry to go away as badly as you do. But as Michael Sinz once said, "Programming is like sex, one mistake and you have to support it for the rest of your life."

The registry COULD have been a good idea.. err... nvm.

What the registry should've been was a database tracking localized .ini files, which could be binary or plain-text files containing the same information. That way if you just delete the folder containing the application, the OS can't find the file and assumes it's gone, or asks to search for it.

The only thing missing from linux is a microsoft's media center. Until I can figure out how to hook my xbox360 and my laptop/pc together so I can watch TV, use that neat sports thing, and download showtime movies.. I don't know if I can justify the switch. Gentoo is by far my favorite OS.

The registry has one important redeeming quality when compared with keeping settings on the file system: it's extremely fast. The OS keeps the registry in ram, where key requests are returned almost instantly. Compare that with the number of disk seeks required to retrieve a value from a config file in /etc (hint: it's a minimum of four, and we haven't even started to read the file yet).

Of course, this matters much less now than it did in 1995. Most applications load their settings once at start up, and even among those that check while running very few require this level of performance tuning. There's really very little need for an application to keep any data in the registry any more.

Even so, I think the speed improvement would be enough to make up for the deficiencies.... if, that is, the regestry were organized in a sane manner. I'm sure it's organized in a way that makes perfect sense from the point of view of the kernel, some senior developer at microsoft, or something like that. However, since we're using a database that's almost always in ram that won't matter nearly as much as being organized in an intuitive manner for the user (or if you accept the idea that users shouldn't ever edit the registry, than for developers and technicians). And this is the area where the registry fails miserably. I have four places in the registry I use on occasion (LM->Software->MS->Windows->CurrentVersion->Run/RunOnce/Runservices,
CU->Software->MS->Windows->CurrentVersion->Run/RunOnce/Runservices,
LM->Software->MS->WindowsNT->CurrentVersion->WinLogon, and
LM->Software-> (useful for removing old software crud if an application didnt' uninstall correctly).
). Beyond this I'm completely lost and I've spent as much time poking around the registry as anybody.

I agree with this article and all of you. The registry is a great place to put information about installations of all importances. And even though it is not secure and has the potential to break your computer, we need this stuff or you're not going to go anywhere.

the registry was a bad idea because it is a single point of failure

However there are three types of settings

User settings - i.e. how I want the program to work/look for me

Default Settings - how a new user sees the program

System settings - how the program is confgured to work if the system runs it

These need to be stored in three different places!

So an SQL server needs only system settings and should have a configuration program that manipulates them (dosn't matter where/how it is stored as long as it's fast)

A user program needs some default settings (read-only to most users) and username specific settings which should *not* be in a central registry or ini file in the program folder or system folder (they should have no access to this (something Vista *finally* got right)
and ini (or whatever) in the users folder is ideal ...

Have to agree with Jeff on this. Classic example of filling a need in the wrong way, and millions suffer.

@Jaster

User settings are stored in NTUSER.DAT and UsrClass.dat in your user profile.

Machine and default settings are stored in %systemroot%\system32\config (in serveral files) - read only for standard users/LUAs

System settings are stored in %systemroot%\system32\config\systemprofile in NTUSER.DAT and UsrClass.dat - read only for standard users/LUAs

systemprofile and UsrClass.dat have been added with Windows 2000 the rest is unchanged since at least Windows NT 4.0

JM wrote "You have a server, you have multiple users with personal settings and/or state to maintain - why should they "hit the same file"? Shouldn't any sane application provide each user with their own settings file in the their own home directory?"

HKCU (per-user settings) is stored (per default anyway) as %userprofile%\ntuser.dat.

I.e. not hitting the same file as the system registry or other users.

As for storing separate settings files... What exactly is the big difference between %userprofile%\settings\vendor\app and HKCU\Software\vendor\app? (except one is one or more files in a proprietary format, while the other is a collection of values using mostly standardized data types for storage)

Guys... .ini files is not the solution. XML configuration files tend to be glorified .ini files. _What_ are you guys trying to solve?

"the registry is bad, m'kay?"

Application settings should not be stored with OS settings! You should be able to back an application up merely by copying the appropriate "Program Files" directory.

There is no reason an INI file or an XML file couldn't also be cached in memory. There's no reason an OS API couldn't do this automatically for an Application. For instance, when an application loads an INI file the first time through an OS API, the OS could pull the data into its own internal DB and return data from that. It could watch the original INI file even when the application isn't running and then suck any changes into that internal DB. Viola! You've got a system with all the advantages of a single settings DB with all the advantages of letting the user edit simple text files.

You've summed up most of the reasons I hate the registry. I wanted to mention one more, though.

1. The Registry Editor (regedit). It's slow, has very limited functionality, and a confusing interface.

Of course, the whole "hive" concept is confusing anyway. But how about a search that doesn't revisit a node in one hive if it's visited it already in a previous hive? For that matter, how about a search that gives you a list of all the matching keys/values, instead of doing them one at a time?

How about a way to indicate what values are "correct" in the data? I'm thinking, for example, about regular expressions to constrain text entry, or specifying valid ranges for integer values.

How about recording which application created or modified a key, so that we don't have to rely on applications undoing all their modifications. Because many applications are awful at it, especially if you install as one user but uninstall as another.

sburnap: "You should be able to back an application up merely by copying the appropriate "Program Files" directory."

Absolutely, but less and less apps actually want that, because they store the license key under HKLM\Software\Vendor\App which tends to be local to one computer (or worse: some hidden location either on disk or in the registry - or scattered around!). The app folder could otherwise reside on some network drive somewhere.

And apps using COM (as previously discussed) have less choices. (where would COM registrations go, if not to some centralized system-maintained repository?)

Surprisingly many apps work just fine if you simply copy their files -- the biggest problem is usually with apps using DLLs placed in the %systemroot%\system32 folder.

I remember the first time I installed IE on a Mac. I believe it was IE 5.1 and I was on a G4 running OS X.0. I downloaded it, decompressed the folder and BAM, there were instructions simply telling me to copy the IE folder into the applications folder and it would be ready to run. I stared at the monitor for a while, flabbergasted at the ease of installation. I drug the folder over, created a shortcut, and it all worked perfectly. Oh what sweet irony, the Microsoft developed product is more easily installed in the Apple developed OS. Of course I knew even back then, it was because OS X lacks a registry.

I'm pretty sure even the old Windows 3.1 (the one running on top of DOS) had something reminiscent of the registry. Back then it was only used for registering OLE servers though.

Just checked it, and while a basic, fresh installation of Win 3.1 only has a file type registration editor I'm still pretty sure there was something more advanced. I think it appeared after installing programs supporting OLE 2.0 or whatever, I'm pretty sure MS Publisher 2.0 is such a program but my old diskettes with it no longer work :(

> Hell, the .NET libraries for manipulating the registry aren't even in the System namespace. They're hidden away in the Microsoft namespace, where only desperate people and VB programmers go.

Great point. I should have singled out .NET here as an excellent Windows role model. .NET barely touches the registry, ever, which is the way it should be. Even the GAC, the most registry-like thing in .NET, is filesystem based in the c:\windows\assembly folder.

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.

@Jeff

You should start regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\System.Object and the look around

Not exactly "NET barely touches the registry" and all the System stuff is in the GAC. The same happens witch any assembly that is installed in the GAC and is COM callable.

The registry also still isn't the ONE place where you can find things like application settings, even for modern programs.

I reflected upon this the other day on my blog...

http://dansdata.blogsome.com/2007/08/18/they-seek-config-here-they-seek-config-there/

...and some commenters chimed in with some interesting extra info.

When I write freeware apps I always use YAML. It's like XML but without the angle bracket tax.

I've always liked the idea that if you want to delete an app, you delete the directory hierarchy and that gets everything.

Simple.

I never thought there was anything particularly wrong with the registry despite having hosed a Windows installation by bad editing. Once I saw how OS X does it, though, I realized that the Windows way of doing it is horrible. You cannot easily extract a section (say, for an application) and move it to another machine without knowing exactly where to look, and it's different for every application and may not even be a single location. Contrast that to OS X where it is (almost always) a single plist file that you can move to another machine and you've effectively transferred all your settings for that application. Want to restore settings for all your applications? Just copy over the whole folder. Much more sane IMHO.

As a mac user and programmer. I do not envy you microsoft guys.

You're preaching to the choir, Jeff

Don't forget Mark Russinovich's regmon registry monitoring application. (Functionality more recently also rolled into his procmon (ProcessMonitor) application.) Fire up your application and see what it reads/writes.

<a href="http://en.wikipedia.org/wiki/Mark_Russinovich">http://en.wikipedia.org/wiki/Mark_Russinovich</a>

>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.

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 think the registry is better left for more complex application that require resources as such. I have an rather simple application that has been out for a while and I use the registry settings to store a few formatting options, like window size, what tabs were selected, etc. to give a more consistent user interface when the user comes back in.

So following the "standard" I put these settings in the registry. However, I started running into some problems during the beta cycle where people were closing a tab and the UI wasn't catching it, so their tab was "lost forever" since the app saved it's state to the registry upon closing. Trying to help people navigate through that is nasty.

I cleaned up the code and the registry settings remained into the production, and I made sure the installer removed the registry keys as well. However, now that I'm working on a 2.0 release, the thought occurred that my program is so lightweight that it would function quite nicely on a USB key and given the nature of the program (deck building program for a TCG), it would be perfect for a kid to bring their USB key with the app over to their buddies house, fire it up, and work on things from there. But with it looking/writing to the registry, this becomes an issue.

So my 2.0 release is going to leverage the app.config file to read/write most of these things. None of my settings can do nasty hacks, other than hide/show some tabs and make the window tiny and the advantages I get from it are great. Plus I like how most of your middle/light apps functioned in the old days, you put the EXE on a disk and ran it, no need to wait for things or pull in resources, you just ran it.

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:

http://msdn2.microsoft.com/en-us/library/bb625960.aspx

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 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"?

Imho, the registry is still good for "plugging" programs into the OS (contextual menus, default programs, etc) and for enumerating the hardware. What really should reside in xml/ini files, in user settings folder or program folder, are the HKCU/SOFTWARE/<vendor> and HKLM/SOFTWARE/<vendor> keys.

Jeff, I'll second the view that game installations intentionally break if you reinstall the OS or parts of it. Part of a brain-dead mentality of making the user keep the install disks, and better yet going out and buying a new set.

In reading all the comments, no one has had much problems with INI files. Wow. I can remember fielding calls from clients who directly edited the files (encouraged by support), and then wondering why the changes didn't work. Then you have to figure out if they deleted a line, put invalid characters in it, or as was often the case had multiple copies of the INI scattered around the file system. I was happy REGEDIT was so hard to use in cases like these.

It's faster for an install to look for specific keys in the registry than the whole filesystem (and possibly network mounts) for previous versions.

Your points are valid, but INIs and XML files have their own faults.

>The question we should be asking ourselves is "as software developers, how can we change or fix this"?

Change it? Not until after I retire ;) That easily corruptible registry is job security for some of us.

Of course, I'm kidding.

I have to disagree with this article wholeheartedly. The general registry idea was a good idea, just not as it was designed. Here's how I would have designed it in retrospect:

1. Create logical packages of registry items. Every app creates its own logical area, which is orthogonal to where the keys physically exist in the tree. A package can be simply installed and uninstalled with a single API call, as well as automatically in Windows Installer.

2. Give keys an expiration date and force developers to think about how long they should last. This gives Windows the ability to more intelligently flush things out. Plus, it makes a lot of registry-based dev cases easier (such as timestamp keys).

The same arguments about the registry could be applied to any Application or System that uses a database as a back-end.

You know, like Oracle, MySQL and SQL Server. Somehow, businesses trust storing all their critical data (payroll, AP, Billing, sales, etc.) in a "single point of failure".

Yet they manage to stay in business.

Granted, the registry might not have been as robust, but that is an implementation problem not a design issue.

I think the real problem is that in the same way that a poorly written application can mangle data in a DB, each application/installer that uses the registry is responsible to manage it's own data.

For example, EBay would be a mess if everyone could add data to their database directly - instead you go through tightly controlled web and rest/ws interfaces.

On the other hand, by not putting in strict interfaces, the registry lets developers add data in almost any format and structure. Hence, it can appear to be a mess to an end-user.

You're STARTING to wonder if the registry was a good idea?

Several people brought up plist. Man, that's a format that is totally braindead.

<key>key</key>
<value>value</value>
<key>key</key>
<value>value</value>

Talk about a total bastardization of xml. Shows a complete lack of understanding from the format creators. Plus it's a bitch to parse because you have to keep track of the previous sibling.

"I used to sit beside the guy who invented the registry at microsoft. It was designed as a *temporary* measure to deal with the .ini file system mess." - Raymond Drewry

Personally I think the windows registry is the weakest and most outdated aspect of the entire system.

But personal opinions aside, the registry should not be trusted with any autoloading of applciations ever.

I'm not a developer, but why are 3rd party apps even in there? I use mostly open source applications to do everything I can.

All I do is go download the zip, make the folder in program files, extract, make a shortcut to the desktop and run the main programs exe.

no installer, no registry, no garbage.

Does it have something to do with multiple users?

I mean to me, an application needs to do two things in the registry:

1) establish any file associations.
2) setup its checksum for authorization if its payware.

Aside from this, what the hell is any application doing in there?

And if they must be in there, WHY IS IT NOT ALL IN ONE FOLDER?

This is seriously pathetic that systems can be crippled so badly by malware/spyware from the abuse of the registry system and also the fact that no one reads any prompt windows.

The kernel should only load apps that appear in a SINGLE .ini file or SINGLE wherever if you want it more secure.

That's it. One place, or else it doesn't open.

msconfig is not enough.

It just irks me how well other operating systems can handle simple things like this, when windows can't.

Windows does many other things so well but this one vital piece is left out.

Its a double edged sword.

my.02

I don't get it. What's wrong with storing application data in the app's installation folder? More specifically... why are applications denied write access to their own installation folder?

I would like to second Andy (above) and say the new font is almost unreadable (in either Firefox or IE.) Can we please maybe have the old one back? I had to increase the font size just to read your post.

I couldn't help it - I just had to post my comment from earlier this month....
-------------------------
http://www.codinghorror.com/blog/archives/000929.html

I think we can kill a lot of birds with one stone here....

Am I the only one who doesn't understand the need of 'installing' the vast majority of applications? I can understand why we need to install system components. Things like DirectX, .Net Framework, etc...but why do I need to 'INSTALL' games or applications?

If I have a game, I want *EVERYTHING* I need to run that game in the folder I tell it to. The registry is a huge mess....screw it. Everyone, *stop* using the registry. I'd rather see a 'config.xml' or a 'config.ini' than have to spend hours digging around the registry for whatever the application added.

The vast majority of .DLLs and crap that will get copied to the system directory will never be used by anything other than that one game or application and SHOULDN'T be put into the system folders.

When you execute a file, by default, it should ONLY have read/write permission to the folder it is in, and any sub folders.

If I'm running IE and browse to some shaddy site, IE itself, should only be able to access the folder it sits in, and sub folders. That means, ALL of the data related to IE can be found in the folder and it's sub folders.

If I install another copy of a Windows OS - I shouldn't have to 'reinstall' any of my games or apps. I should be able to browse to the folder it lives in, run it, it should work. See, during the install process a bunch of crap is put into little hidden spots of the registry and files are copied all over you HD. Without those files, the game won't run....so you have to reinstall all of your games. It's crap.

What I'd like to see is a filesystem based security system that views individual executable files as 'users'. Each app, each game, each EVERYTHING, you can run has individual permissions that you can look at and modify. By default, it can't do anything but read and write to it's folder and subfolders. If you want IE to be able to put files in C:\MyFiles - then you need to set the permissions of C:\MyFiles to allow IE access to write to it. Anytime an application attempts and fails to read or write data that doesn't belong to it - you'd see an error message. You know what file did it, and what it was trying to get at.

Taking it one step further, using this model, the VAST majority of applications could/would run just fine as long as the appropriate updates were made. The few installs that really should be 'installed' in the current sense are mostly well-known MS or other big name company products. If I go ot install the .Net Framework that *should* be a real install, but MS could certainly give it a 'stamp' of approval; just like it does with signed drivers.

If someone gets a 'HappyBunny.exe' and they run it, it won't be able to do much of ANYTHING. It has read/write access to some temp folder under IE. Even if it exploits some sort of buffer overflow, or something along those lines, and can excute code, the IE process, only has read/write access to it's folder. If the application requests access to other folders, the user would get the error message with a 'allow/deny' type choice and then, if they allow, since HappyBunny.exe isn't digitally signed by MS - they get a big BIG ugly warning saying that there is virtually NO REASON for an application to need more access.

Administrator accounts could grant the programs access to system folders. Regular accounts couldn't. This would *only* affect the installs of software that has a legit reason for accessing system files (virtually none). Everything else could be installed from the regular accounts.

RobDude on August 14, 2007 04:29 PM

Looks like nobody here actually administers a network. XML files in the same directory as the EXE file - real smart when c:\program files is READ ONLY to the average user. (It's for stupid programs like this that Vista introduces a virtualisation trick where programs can apparently write to such areas - they can't in reality; it gets shunted into a per-user application compatability area.)

Or how exactly administrators are supposed to roll out an individual setting - you're proposing they all learn XSLT and run an XSLT processor at logon? Heck, I'm also a dev and I have issues reading XSLT!

It's really nice knowing that an app's config is likely to be in hkcr\software\vendor\program; and that I know anything in hkcr will roam properly when the users logs onto another machine. (Which happens an AWFUL LOT in the corporate world.)

A bunch of silly files means that logon processing slows down with roaming profiles. Thats assuming the dev put the files in the correct place.

KG: Of COURSE applications are denied write access to their installation folder. If you don't deny the user write access to there; the user will screw around with it and muck everything up. (When an application is deployed by Group Policy, the MSI runtime will run with local-machine admin privs to install the package.)

Honestly, I suspect too many devs don't know the real world where supporting a hundred windows computers is considered small potatos.

"Honestly, I suspect too many devs don't know the real world where supporting a hundred windows computers is considered small potatos."

Of course I don't administer 100 computers AT MY HOME. I have VERY different needs than do medium/large-sized companies. Convenience is more important for me than dummy-proof security - I understand it's the other way around for you. So why should my OS contain all the same restrictions?

That's why we have /etc

Geez you make me feel old.

I remember back in the day when applications scattered ini files (and other config files) randomly about my hard drive. From applications that required their ini be in c:\windows (not d:\windows, or bob forbid, d:\apps\SomeApp) to ones that liked to have c:\SomeApp for the application, c:\SomeData for the data and c:\config for their .cnq files (hello Canon)). Oh, and the inevitable editing of system.ini and so on, which often had humorous results (if you weren't the one trying to make it work).

The registry was a distinct step up from that mess.

But it just proves the old adage: there's always a better fool.

I just want to make clear that regardless of my earlier comment, I'd like to drop the registry for many things as well, if anyone could come up with a half-decent way to overlay required settings on config files in a centrally-administrable manner. (In such a way that the apps know, so settings can't just be changed back every time the app is opened.) I know for a fact that this is one of the issues holding back Firefox adoption in some businesses, having heard from other admins. But the open source community doesn't see this as a need at all, and perhaps actively loathes central management. I've been hoping Novell or Red Hat would come through for a while, but not yet.

I like the idea of "only have write access to your own folder", which vista's and terminal server's redirection partially gives you, except that it's the user's home folder

Really, the number of developers who think that the one true home for ini files is the program folder rather shocks me. I guess that happens when you've never touched a machine that someone else uses. Mozilla does an excellent job with registry, centralized, roaming, and local data; more developers could take a few tips from them instead of outright rejecting alternatives. (Aside from the fugly Mork files.) All it needs is a way to lock down without a custom plugin and it would be perfect.

My vote is for getting rid of the Registry.

As an aside, XnView is one software that gives you complete choice - you can set it to save to the registry, an ini in the program folder, or in the user's application data. A little bit of stuff always gets written to all three, but only a couple of small, unimportant files.

Portability and debugging are enormously easier when the software actually gives you the choice.

How appropriate. I post about the aggravating nature of the registry last night, today I get to "fix" a DVD-R drive that mysteriously fails to load with error code 39, by making this cryptic registry change:

http://forums.techguy.org/hardware/572840-dvd-burner-stopped-working-drivers.html

(see post #4 -- remove "LowerFilters" from the "{4D36E965-E325-11CE-BFC1-08002BE10318}" key under HKLM\System\CurrentControlSet\Control\Class)

Works like a champ now. :P

I don't think I have ever agreed with anything you have ever posted more than this.

DOWN WITH THE REGISTRY!

I personally try to only use INI files and XML config files. Every once in awhile I must admit that I sin and store stuff for my applications in the registry.

I think alot of the posters are missing the point: the registry is a tool like any other. It has both benefits and drawbacks.

Pros:
* Database-like architecture means reads and particularly writes are fast
* Standard API
* Easy to share among various instances of a running program, run by the same user (yes it does happen sometimes, get used to it)
* Theoretically harder to muck up at a low level than text-based files
* Everything is in the one place

Cons:
* Everything is in the one place
* It is hard to split out the settings for an application. In comparison a gamer-level user can manage to extract file-based settings
* Low level implementation not as fast or robust as it could be
* Cannot use "xcopy" deployment
* COM was built on top: COM is an even bigger problem
* centralised packaging not common in windows: packaging is an even bigger problem
* Contents are not self documenting
* Contents are not externally documented (Try to *accurately* enumerate *all* the com ports in a windows system sheesh!)

-Andrew

Jeff: "How appropriate. I post about the aggravating nature of the registry last night, today I get to "fix" a DVD-R drive that mysteriously fails to load with error code 39, by making this cryptic registry change:"

This is a problem with the device driver. Maybe part of the problem is that since everything is stored in the registry, people blame the registry for everything.

-Andrew

Saying the registry is "obsolete" is ridiculous. The article and some of the comments seem to imply the registry concept was OK in it's time, but is now outdated. Rubbish. It was never OK. The registry never did ANYTHING but break software and occasionally kill your windows installation.

What are the advantages of a single place to store system settings? Is there a single one?

Personally I can see a lot of benefits of having all the software settings in a single database. Per say the registry system is a good way of doing it. At least the basic idea of it.

To be honest, the fact that applications fail when you move them is not the fault of the registry but the application. The developer of the application should have accounted for that and built in a function to update the paths in the registry when the application starts from a new location.

And all applications should have a re-built registry entries function. This means you will have to ask the user to input some information after a resinstall of windows, but it beats reinstalling the application. And to be honest, the average windows user (I hate that statement, but you can't get away from it) does not reinstall windows (as the mater of fact, he/she probably doesn't know it can be done )

My biggest problem with the registry is that it's not really that scalable. It wasn't built for applications of the size and volume we have today. And the number of applications have increased a lot too. So we have a lot of more entries in the registry then it was designed for, thus making it sluggish. Slowing down the computer at an alarming rate. Specially when you install a lot of small applications

There was a comment up there about saving the settings after an uninstall of an application. I see this as one of the main reasons why the registry is so slow. Cos all the applications leave a lot of registry entries when they are uninstalled. If you are going to use it or not.

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.

http://channel9.msdn.com/ShowPost.aspx?PostID=148820

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 :/ )?

I have 1 word for you:

Linux

http://www.youtube.com/watch?v=EwL0G9wK8j4&mode=related&search=

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.

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.

there's nothing wrong with the registry. A registry is better than having 10000000000000000 small files.

Using a text only browser (damn your CAPTCHA!)

Qt, by Trolltech handles configuration files quite elegantly in a cross platform manner. It uses the native settings saving mechanism to handle any custom preferences. Thus, if Microsoft made a substantial change away from the registry, Qt based applications would not need editing!

Of course, knowing Jeff Atwood, chief architect of Microsoft cocksucking, he'll rather stick to inferior technologies.

For someone just beginning to question the registry, in a dry blog post, it's clear that sensible advice like "Use Qt" won't become apparent for another ($NOW - $INCEPTION_OF_REGISTRY) years.

I'm not so sure I agree.

As many people have stated here the registry is just a tool which can be abused, but then again any configuration store could be abused. The abuse comes from the fact that many applications change settings that other applications are dependant on, but I would have to say that in many cases that is not something we can get away from.

If we wanted the settings to be one specific value forever then it would be hard coded and not in a config file. The whole idea of config files is that values can change depending on need. So this kind of makes this whole rant a bit obsolete.

The main issue with the registry is that it makes your applications non-portable. As an old Mac user, I miss the days when you could have an app on an external hard drive, take it to a different machine, and run it there.

And the sad thing is, there's *nothing* gained by using the registry that makes up for this crippling loss of functionality. In fact, the registry will accumulate, over time, numerous errors that lead to the need to reformat windows every other year or so (or just resign yourself to the errors).

The main purpose of the Windows registry wasn't to store application settings in general, it was to store OS settings and application information which can be shared whith the OS and potentially with other applications. This was supposed to be something helpful in order to allow the OS to be aware of the installed applications.

- The original goal makes sense: It allows to increase OS usability (centralized OS settings, uninstall points, known file extensions, etc.).

- However these usability improvements have been accompained with real big drawbacks: Portability of applications, difficulty solving installing/uninstalling/updating problems, reduced OS transparency, and the idea that we have some kind of 'tumour' within our machine which grows without control. However the registry cannot be blamed of all the vulnerability issues just because Windows home users work usually in root mode, this is a cultural problem.

- My point is that all these problems are not derived from the original idea of a 'registry', but from its implementation and use.

Three letters, XML.

The Windows Registry was not introduced with Windows 95, it was introduced as part of Windows 3.1 and NT, though most applications (and most of Windows) at the time still used INI files to store configuration data. There were exceptions, which I recall from my early network administration days: Novell WordPerfect, for example, used the Registry previous to Windows 95.

As for whether the Registry was a "good idea," yes, actually it was. The alternative was a proliferation of INI files, which was a horrible idea, even then. Microsoft also had concerns about the integrity of plain text files. Obviously, the Registry got complicated and convoluted, and today it's a mess. But for the time, it made sense, just like floppy disks, CRT monitors, and other technology that seems quaint today. We should be using XML files for configuration data today, I suppose (i.e. proliferating text files). In 20 years, that too will seem silly.

--Paul
SuperSite for Windows

I would have to definately agree with you. Our company has moved off of using the registry to using the application data directories for storing settings in xml.

Interesting-- Paul Thurrott is right, the registry existed in some form as far back as Windows 3.1:

http://www.gaby.de/win3x/etips.htm#regedit

Oh yes. Let's all move our settings to XML configuration files. I don't believe config files are a better solution. We just exchange one set of problems for a different set of problems. Now instead of having my settings strewn throughout several different hives and keys in the registry, I get to try and find my settings in a series of files which may/may not be logically named and buried in one of several directories. For example: I want to copy my setting for MS OneNote 2007 to another machine. I have OneNote settings stored in AppDate/Local/Microsoft/Office, AppData/Local/Microsoft/OneNote, AppData\Local\Apps\2.0\Data\JJ81VLRM.H8Z\CLHYBMCG.2TG\onen..tion_f1fe1dc54fbb5b9b_0001.0000_87e1612fa5f8a27f\Data, AppData\Local\Apps\2.0\WJ7L7QJ0.11R. And this is just in the Local directory. I haven't even looked in LocalLow or Roaming, much less in the AllUsers or Default folders. I am no more certain that I will capture all settings using the configuration file method than I was certain I would find all the settings using the registry. Oh did I mention the fact that since I am forced to elevate priveleges to install any software, I might be lucky and also have some key settings stored in my administrator's folders. What a wonderful solution. This is SOOOO much better.

The guy at Microsoft who accidentally created the Windows Registry agrees with you! Tony Williams. See his Code Behind interview where he is asked about it. http://www.researchchannel.org/prog/displayevent.aspx?rID=5212&fID=1806

"10 years... and I'm starting to wonder..." LOL!

Made my day, thanks!

I totally agree!

I might choose a different screenshot.

I think that there have been a number of good and bad points made. Sadly, they have been completely lost inside the myriad of "me too" type posts (e.g. "it's called XML", "use Linux").

I will attempt to summarize all of the points made here. Please excuse me if I miss anything out.

========================================
Positives about the registry:

* It's a single place for looking for most settings, rather than having numerous config files scattered in any number of locations.

* For applications which use the registry correctly, it's a convenient and consistent place to store information.

* Every key (folder) in the registry can be secured, providing fine-grained control over which items a user can see or modify.

* You don't have to worry about file system permissions when modifying global data.

* Having a binary storage in memory is more efficient than using lots of files on disk. For example, if you use an INI file, it gets rewritten every time you change even a single entry.

* It is automatically backed up by Windows, so you can revert to a "last good" state if needed.

* By being an opaque store of data, accessible only via APIs, it's harder to corrupt via manual editing. An XML file may be rendered useless by missing a single character.

* The HKEY_CURRENT_USER hive roams with the user's profile, making it portable.

========================================
Negatives about the registry:

* Being an opaque binary blob, it's a lot harder to make manual changes to should anything get corrupted.

* Because the registry is so widely used, any corruption will affect multiple programs, not just one.

* Because of its size, it's possible for applications to hide data just about anywhere. This makes some settings incredibly hard to find.

* There is no enforcement of structure. So long as a user has sufficient access rights, any program they run can write to anywhere in the registry.

* It's a lot harder to extract settings for a particular application from the registry.

========================================
Issues that will occur regardless of storage mechanism:

* There will always be cryptic or hard-to-find settings. Using Jeff's example of the DVD burner not working, the issue was with an incorrect configuration value, not the registry itself. If the data was stored outside of the registry, it would still require some kind of configuration file change.

* It's possible to stop an application from working by editing or removing configuration values.

* Configuration files and entries can be scattered in any number of locations, making them hard to back up or remove.

* If an application is removed, but doesn't clean up after itself properly, there will always be some usage of resource(e.g. disk space). In the case of the registry, it may also use up some memory.

========================================

In the end, it's up to developers to code appropriately for the situation. The registry is a good place to keep settings, so long as it's not abused. Other times, it's a better idea to keep configuration files on disk.

No matter how you look at it, the registry is just a storage tool for settings. It can be used, and it can be abused. Sadly, it's been far too abused, and this is the cause of all our pain.

Just a note to those who want some sort of control based on the application being run... Sadly, it's not that easy.

There are just too many ways to get an application to run whatever code you like:

* Modifying the application on disk (the same way viruses do).

* Inject a new thread into a running application. Any check of "which executable is running this code" will report that application.

* Locating a snippet of binary code that can cause execution to temporarily enter the third-party application, then back into yours. This would allow you to pass any checks of the call stack.

That's why operating systems tend to use user-level permissions rather than application-level permissions. It's much harder to spoof a user than an application.

Just an observation, but almost all of the posts talk about "moving an application" by copying the install folder somewhere else. This is fine for statically-linked stand-alone apps.

How do you handle DLLs? Put a copy of every DLL that your app links with in the app directory? How about the DLLs that they link to? Oh, you want to have a common place to keep system DLLs so they don't have to be in every app dir? What do you do about apps that need different version of a system DLL? (It's called DLL Hell).

How about newer apps that communicate with other apps (photoshop and a scanner control app)? How about all of those COM interfaces that let apps bind at run-time? How do I find RPC functions in a common place?

I think that if you go back and substitute a substantitive app, perhaps even a browser like FF, you either have a huge app directory filled with everything needed to implement modern componentized applications, or you have something like the registry that can be located by any app and queried for the location of common shared copies of things.

Do you really want to download 100 or 200 mb install packages that have all this stuff in them? As bad as the registry is, the world of .rc (er, .ini) files is as archaic as the isolated apps that used them.

Myself, I kinda like being able to drag-n-drop things in the GUI, mash up some COM components into a new app without rewriting everything from scratch, and have my Java call C++ functions from a DLL that is common to some functional domain.

Does anyone not use these kind of apps? If not, other than writing bash scripts or perl, how do you create extensible, versatile tools to solve your problems?

Perhaps the registry is like what people say about democracy == it sucks, but it's better than the other forms of government out there.

I just wanted to make sure your discussion covered a large surface of the apps available to run on modern OSes.

JS

Nice posting, though we all know that the Registry was in fact one of the bricks in MS's great masterplan for obfuscating all other's code to such an extend that they could over time easily take over all the application vendor's revenue by supplying better solutions built on "local storage".... ;)
(JOKE...!!)

.t

> How can we make this better?
We really have 3 different kinds of settings.

1. System settings
Store these in the existing registry for compatibility reasons or better yet, upgrade the registry to MSDE as suggested earlier.

2. Application settings
Store these in a centrally located location with a separate file for each application to make it easier to move application settings between folders and pc's. I don't buy the myth that this will slow down apps as the extra 200ms needed to read this file easily outways the performance hit for keeping a 500MB registry file in Ram (or a cache). Besides you can cache the file anyway.

3. User settings
User settings should be stored in a folder under "My Documents" and called something logical like "My Settings". This allows you to back them up, move them between machines and ideally, transfer them to a web service so you can access your settings anywhere on the planet.

Its an evolutionary process. The Registry was brought in to fix the problems caused by INI files and ended causing a whole different set of new problems. Think of how many attempts Microsoft needed to get ADO into the version they have now.

I agree with Jeff, at some point one has to stand back and take the 2,000 foot view and rethink things.

The Gassy One posted on His Blog:

Read This Now!

I am 100% on-board with this one, and am currently writing registry-free applications!

BTW, that reference comes from another favorite blog.

Sean: "Talk about a total bastardization of xml. Shows a complete lack of understanding from the format creators. Plus it's a bitch to parse because you have to keep track of the previous sibling."

It isn't a bitch to parse because you simple look for a tag and then the following item is the object. Plus it's pretty easy to parse on OS X:

[NSDictionary dictionaryWithContentsOfFile:@"pathtofile"];

or

[NSArray arrayWithContentsOfFile:@"pathtofile"];

You've now got the whole file loaded into an array or a dictionary

Registry is not going away. If Symantec is not paying for this 'feature' such that it can't 'possibly be removed from windows' then they should. And the hackers, and the IT staffs...

"How do you handle DLLs? Put a copy of every DLL that your app links with in the app directory? How about the DLLs that they link to? Oh, you want to have a common place to keep system DLLs so they don't have to be in every app dir? What do you do about apps that need different version of a system DLL? (It's called DLL Hell)."

Essentially, the problem is that the installer has to be used as a priviledged way of putting an application on a computer. If you reformat, or move to a different computer with the same share but different installed dlls, then things break.

I've long thought about a way of trapping all the changes an installer makes to disk and then packaging them so that the folder could be simply copied from one computer to another. Use a sort of secret directory which contains the registry keys and files installed to external directories. When taking it to a new machine, it would essentially look through the secret directory as a sort of $PATH for registry keys, and install them if they don't exist.

And yes, you could cache dlls in that directory (hard drive space is cheap) and when running for the first time on a new computer, go through the same process an installer does, examining the computer for dlls and copying the needed ones to the new machine.

Should be a relatively straightforward hack, especially if you can easily detect when an installer is running.

I think what we are going to see is virtualization of the registry and the equivalent of app-armor. Every app with run either in it's own virtual space or a protective shell. At least on windows. What I really wish is that linux/unix would move all it's config to xml. intead of me having to be some sorta voodoo shaman to know that 1 extra tab can spell doom, and what all the parameters means

I don't know what UNIX convention you're talking about... AIX was built with a registry. And officially, you only use SMIT to deal with it.

How do you handle DLLs? Put a copy of every DLL that your app links with in the app directory? How about the DLLs that they link to? Oh, you want to have a common place to keep system DLLs so they don't have to be in every app dir? What do you do about apps that need different version of a system DLL? (It's called DLL Hell).

--Point: How about letting the admin user decide? A properly written dynamically linked application doesn't -care- whether the DLLs it uses are in the application folder or elswhere in the path. So let the -user- make the choice.

--Oh, and BTW, what's a "System DLL"? I have never seen an app break because it needed a different version of Kernel32, User32, etc. Only because Microsoft arbitrarily decided that MFC42.DLL, COMMCTL32, half of Internet Explorer and Media player are "System" DLLs do we have most of these DLL issues.

How about newer apps that communicate with other apps (photoshop and a scanner control app)? How about all of those COM interfaces that let apps bind at run-time? How do I find RPC functions in a common place?

--Same way they always have. Look in the system configuration files and environment space. MS doesn't have a lock on scanners and inter application communication, and they didn't invent RPC.

I think that if you go back and substitute a substantitive app, perhaps even a browser like FF, you either have a huge app directory filled with everything needed to implement modern componentized applications, or you have something like the registry that can be located by any app and queried for the location of common shared copies of things.

--Point: actually, any number of "substantive" apps, including Firefox, Thunderbird, OpenOffice, MySql, Apache, the GIMP, and hundreds of others DO NOT REQUIRE INSTALLATION...at all. They come with installers, which allow you to perform optional tasks, such as select components and register file extensions, etc. But they work
just fine being copied rather than installed. Check out PortableApps.com; this lets you carry several "substantive" apps around on a 2 GB thumbdrive, with room for over 1 GB of data. (Yes, I know the default uses an install; my point is that it's not impossible to make copy-only apps; it just requires you to try)

Do you really want to download 100 or 200 mb install packages that have all this stuff in them? As bad as the registry is, the world of .rc (er, .ini) files is as archaic as the isolated apps that used them.

--That's also unnecessary. If a shared component exists, use it; if not, disable the function that uses it. And, in fact, MS is shipping larger, not smaller packages.

--I favor something the Open Source community is doing: multiple download links, on the order of "If you already have Gtk/Java 1.4 installed, you can download this. If you don't, download this, which includes everything." Simple, direct...all it requires is treating the user like a reasonably intelligent person, not a feebleminded click-monkey.

Myself, I kinda like being able to drag-n-drop things in the GUI, mash up some COM components into a new app without rewriting everything from scratch, and have my Java call C++ functions from a DLL that is common to some functional domain.

Does anyone not use these kind of apps? If not, other than writing bash scripts or perl, how do you create extensible, versatile tools to solve your problems?

--Point: Libraries, static and dynamic,a dn decent tools; that's it. Check out some of the non-MS things out there. RubyGems, Gtk, a lot of C libraries and a whole slew of reusable components. MS didn't invent code reuse, and they haven't perfected it.

Paul Thurrott wrote: "As for whether the Registry was a "good idea," yes, actually it was. The alternative was a proliferation of INI files, which was a horrible idea, even then."

Actually, proliferation of ini files was only *an* alternative. The choices were not limited to ini files or Registry.

I think the main problem was the 80s-vintage concept of disk usage and user file management: one user, one machine, little or no structure beyond the Windows directory (or the System Folder on Mac OS pre-X)

If the only thing you, as an app developer, can depend will be on the customer's disk are C:\, the Windows directory and the application's folder (if there is one) then it's natural for ini files to start piling up in c: and c:\windows.

When you add more structure to the filesystem, and have user accounts (even on single-user machines), and home directories, then there start to be places to put preferences that make more intuitive sense, and keep user preference information from corrupting or clogging up system information.

So, lacking the structure in the filesystem, it was provided in the Registry (in addition to using the Registry as the central switchboard for system RPC, a rather different function).

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 :)

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.

As usual, the big problem comes from the complete lack of decent security in windows and the fact that that to get it to do anything you have to be running as an administrator, therefore the application/installer you happen to be running has full access to the registry. If you open up regedt32 instead of the normal registry editor you can see that security access via acls to keys in the registry is implemented, but the need to be admin to install apps means it is rendered useless.

The question is really, why should admin rights be required to install anything other than OS software. (As an aside, why should we have to keep installing OS level software in monthly updates?) Because the security was not thought out and the few attempts to implement it have been counter-productive to the point that now to do anything you get an ugly popup confirmation or ten, which then grants the application/installer full rights to do anything it wants, not just install or run itself. Rubbish.

Unix had the concept of user, group, other from the word go, and DOS came after Unix, and Windows in it's 'New Technology' variant came along time after that. If the originaly designers at Microsoft had even the slightest idea of what they were doing (or the people who MS bought MSDOS off), then things would be a way lot easier for us now. I personally would be about a year's worth of wasted man-hours ahead in my life.

MS give me that year back which I have lost due to your crappy design, implementation and marketing/greed-driven decisions I say!

Ultimately I believe the registry was a failure.

Why? Primarily because the state is accumulated through the application of scripts. This leads to a situation where it is very easy to corrupt the configuration.

The alternative? A synthetic view of configuration built dynamically from a set of application manifests. This would allow easier application removal and coexistence. It would also facilitate building security envelope around applications that would shutdown applications that attempt undeclared operations.

c.f. the metabase IIS7, Softgrid

Intelligent discussion about what is really wrong with the Registry seems to be scarce. This is a good start and there are some great comments here! I hope Microsoft is reading.

I've worked in some depth with the registry (on the roll-up-the-sleeves, mucking-it-out level) and here is my own list of problems I've noticed with it, some of them similar to stuff mentioned in the article and comments:

- The registry is "static." What I mean by that is that it typically has no provision for dynamic verification or re-registration of anything, because it depends on these babysitters called installers for its information (and makes the dangerous assumption that they are always right).

- The registry is "sedimentary." Thanks again to its reliance on installers firing off one-time additions of data that may or may not ever be re-examined, stuff "builds up over time," in layers as it were. To make matters worse, new layers can overwrite previous layers entirely. Meaning: the registry is un-journaled and un-versioned on a granular level, which, given the computing power available today and the long-established practices for doing these things in filesystems and databases, is nothing short of criminal.

- The registry stores data as "dumb & de-contextualized." It lacks important metadata that it really ought to have if parties beyond the OS are going to be messing around in it, such as information about key creation and ownership, key history or version, dependencies, cross-references, validation constraints, comments, etc.

Many posters have alluded to the way OS X does things as an alternative possibility; here is some factual reading straight from the horse's mouth on how it does configuration and registration management:

http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/index.html#//apple_ref/doc/uid/10000123i

http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/index.html

http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/index.html

Not saying these are the BEST way or the RIGHT way to do these things, but it's worth looking at for educational purposes.

What's with you weenies and liking XML?
It's inefficient! Use YAML.

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".

Microsoft programs suck in some parts, but so does many other programs too. Here is an example: In VB6 if I search text, then after the search has looped every findings, it disables the next-button (though this does not happen in every case, I don't know in which ones). But what if I want to loop the findings again? I have to close the search dialog and open it again. Sucks.

Example 2. Scrolling with mouse wheel does not work in VB6 code window. Sucks.

Example 3. If I change the letter capitalization of a variable in VB6, it changes every reference to it in the code. But what if I just made a mistake? When I try to commit the code to version control, I notice the mistake and have to go back to the code and fix it. Sucks.

Example 4. In Outlook email program when I try to paste, it pastes also the style of the text. What do they think? That I want to send mails that look like christmas trees? If I copy text from SQL Server Management Console, its usually green and different font if it was inside comments. I just wanted to append bits of information into my mail, but now I have to select paste special first. But paste special was this time disabled in the edit-menu. Sucks.

Example 5. If I borrow net cable for my coworker or otherwise disconnect from the net, then Windows Resource Management still tries to connect into my mapped drives for other machines. Why? Windows waits a minute or so if it can't get into the drives. But if I unplug the cable, then it should not even try to reconnect, because there is no cable in the first place. I know that Windows knows that the cable is unplugged because a yellow tooltip appears and says 'by the way, the net connection is not available'. Sucks.

Example 6. It is really annoying that tooltips pop up everywhere and instantly covering up areas of screen that I am trying to look at. This can be seen for example in Visual Studios. Many times the tips are not even necessary. Why it has to be so f*ing hard to set delays and on/off-settings for tooltips? Sucks.

Why put ini-data into the registry, if they are in ini-files in the first place? If I want to change a setting, I have to change it in the ini-file anyway, if I want to eg. version control the ini-files or something. Sucks.

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.

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.

1) 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.

2) 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 ...

Amen. The registry is a hierarchical database. So is the file system. If you need app/user specific settings, build a heirarchy of folders and files under the working directory of your exe. System settings could be under WINDOWS or whatever. Just as long as you can XCOPY the whole app somewhere else without having to deal with the registry would be great. My suspicsion (I've never investigated this) is that one reason the registry was invented was to overcome slow disk IO back in '95. The reg is just a file on the file system which makes reading settings quicker.

Again I say Amen. No registry would make Windows a much leaner 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

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.

"Think!" this was one of the most intelligent motto in the IT industry.
Do you really think that Microsoft invented the registry as a technical solution? "Think!"... Microsoft is not a thechnical company, it is mainly a marketing think tank... Someone (and I completely agree) says that Microsoft does not innovate: this is not true from a marketing point of view. Think for example the way they invented teir way to approach technical people: they have really invented a new way to sell their pseudo-technology.
So, IMO, the real point is: Microsoft has discovered how to increase coupling. The registry is simply a marketing invention: the more people use it, the more they get coupled with Microsoft products.
Do not forget that Microsoft has invented the "injection of obsolescence" in their product names...
What if someone that worked at Microsoft tells you that the registry was really invented by the marketing team to increase coupling?
The registry IS a marketing weapon, maybe the most powerful marketing weapon ever invented. The registry is mainly a "coupling" techology.

This analysis is somewhat flawed.
Forgive my longer memory, the registry was introduced partly to remove the problems with .ini files. Prior to W95, applications put their settings in win.ini and system.ini, this caused lots of problems as applications edited them incorrectly and could cause the system not to be able to be loaded! Remember all those repair tools that backed up/repaired win.ini files?
If the only problem was to put application settings in one place in the registry then .ini style files are fine. This is very rarely the case. Many applications have settings that can and should be shared by all users of the computer and some that should not. Windows provides LOCAL_SYSTEM and CURRENT_USER branches (hives) of the registry and this is a good solution. I would need per user files and a shared file to implement this in the neolithic UNIX world.
In addition most applications need to sprinkle registry settings within the system's registry keys in order for it to be fully integrated into the system. So, as examples, some sort of control needs component registration, a new file extension needs registration and the uninstaller needs registration so it can be displayed as an Add/Remove program in the control panel. These are the obvious examples but a large product will often have many obscure registry changes it needs to make. I can't see an easy way to effect this with files, or is it proposed that the system has thousands of little .ini files that reflect the thousands of registry keys. Now what would you rather do today?

TEXTO

<A>TEXTO</A>

pah! window.. stupid registry ok it was gd to start with but they could do so much better vista was gonna ditch the registry but some old git said "no im to scared to change" idiots..... GO LINEX!!! :P

pah! window.. stupid registry ok it was gd to start with but they could do so much better vista was gonna ditch the registry but some old git said "no im to scared to change" idiots..... GO LINUX!!! :P

Good post. The registry really sucks.
I'm happy to hear that Microsoft is breaking away from it.

The worst thing about the use of the registry is that it means that you cannot move an application easily from one system to another (which I believe is Microft's main reason for keeping it).

I only use the registry for file associatons if they are necessary. All other state information I normally keep in ini files.

The Windows registry strikes me as something that wasn't designed, it just happened to be implemented from an original concept without refinement. Not good engineering ethos, if you ask me. But then "on error resume next" seems to be staple with all the developers I meet nowadays. Sad.

On behalf of the silent majority...

hmm, I wonder exactly how many applications (and installations of) are out there happily using the registry. I bet if typed '1' then started typing 0's the answer wouldn't fit in this rows="11" cols="70" TextArea.

Perhaps in a few years you'll all be damning config files... Nag nag nag nag, excuses excuses excuses.

Personally I have never had a problem with the registry. True I have not used it since, since, well a long time anyway. I think the single greatest advance, which is actually a throwback, is not having to register components, as with COM.

Get back to work slackers...

Maybe a private registry where the os manages itself....
hardware, os Apps, etc..

A public registry where the app developer can use or not

the Registry has its advantages for the operating system ...but all the junk the gets placed in there is just pure crazy..
i understand the need for localization, but come on the registry is probrably 50 percent junk inside....

DaveP

Sure, anyone who's still got Petzold remembers when they first had an API so they could just manipulate text files in a psuedo-structured format like a .ini without having to roll their own, but realistically there was a search order imposed about where these API's would access the ini files from, and the reason why the apis where developed was because otherwise you could, feasibly, do some bad manipulations, or even just delete the system.ini from the windows home dir because there was no security on it at all if you knew how to flip the s bit.

I'm sure that there was a big buzz in the Windows dev community that the reg was going before NT4 was released, to be replaced with xml files or some such, much like MS keeps on harping about an OO Filesystem, but at the end of the day providing a decent heirarchical model to either with decent security just proved to hard.

They failed to separate the meta from the data, which was what Mac tried to do (not sure how it's going with OS-X or the gritty resource-fork details from before, but this PowerBook hasn't crashed since I bought it 2 months ago before a rapid-onset decamp from the heathen world, and still starts up in 5 seconds after a snooze).

As for DLL Hell, the concepts where being widely discussed at the time, somewhere along the names of Naming, Locating, Versioning, Persitance, Transaction Services etc. But you have to look at the mess that CORBA and the OMG, which was a supposedly open standards based, got into trying to implement all this infrastructure in a very short time. Despite the mess, MS saw this as a big threat to their naiscent distributed computing environment (MS from Server to Desktop which supported Bill's ... on every desk messianic beliefs), so went steaming ahead with their own sad attempts which were not well designed, or in any way enforced on an OS Level. Not even by gentlemans contract. There was no way you could say to MS, "hey, I fancy calling my DDL 'fred', do you already have a fred.dll?" They didn't care.

This means you could put an internal version in meta-data in a DLL, but the OS loader did not in any way enforce the loading of that version or otherwise distinguishing meta data at all over any other DLL hanging around by the same name.

On top of which, as a later attempt, targeted at security issues, they actually disabled the ability for an application to load a DLL in its own directory in preference to one in the system directories. This was a huge mistake (though I may be wrong), but it was one that many developers where relying on, and then got screwed over by.

Then comes the whole activex no sand box issue.

Then comes the COM threading fails issue.

Then. I dunno? Could there ever be a more innept bunch of fools in charge of the desktop computer world?

Have you ever heard of Jaunt PE? It creates for apps portable launchers that hook and redirect registry changes into .ini files. It can be customized to only watch for specific registry calls and can redirect file dumps too. It's like shoveling up the sh*t behind a horse, but it's better than leaving the sh*t on the road. www.portablefreeware.com

What really stinks about the registry is moving your settings from one machine to another. You are forced to go exploring the registry just to find the list of preferred options!

Codewarrior solves this problem by giving user an "Export" and "Import" settings, but not every application does this. A local config file solves this problem in the minimalist way.

A point that no one has mentioned:
How do you store binary data in an .ini file without bloating the file when you encode the binary data in ASCII ala base-64?

The *nix custom of storing config files with a leading period '.' is simple, but it works. Thankfully *nix chose the prefix, instead of the suffix since Windows won't let you create a filename with a single trailing period.

Cheers

I don't see anyone providing a usable replacement to the registry.... but i hear a lot of noise...

I've yet to see an enterprise size LAN 'managed' by a unix box though agree many unix boxes are better as servers for other purposes...

Whatever the solution is, I hope that some day I can install 200 random apps + bunc of devices and when the day comes when I wan to get rid of them that Windows provides nice UI for remove programs / program settings / devices. And when I click remove, I can trust that Windows takes care that no single leftover file or registry entry remains in my system.

This is fine and dandy reading about all the people who hate the reg but... When is MS going to listen?!?! MS should have an advice forum. =)

Dugg:
http://digg.com/microsoft/Why_the_Windows_Registry_fails

This thread started August 29, 2007
and April 5, 2008 people are still
saying it was a lousy idea. Me too!

On August 29, 2007 06:41 PM, Andrew wrote:

Maybe part of the problem is that since everything is stored in the registry, people blame the registry for everything.

It is the single most insightful comment in this thread. Jeff, I'm usually right with you in the things you say, but there are a lot of registry-bashers out there who are not seeing the whole chessboard. Registry pros outnumber registry cons by quite a bit.

What I'd like to see is for MS to start asking that apps and drivers which get logo-certified to have documentation of every registry key they write. MS also needs to field a more prominent, complete, and one-stop documentation of the registry keys *they* write.

One last thing: commenting your registry values is easy! Just write a REG_SZ (string) key as a comment.

The Registry is exacly the 'solution' I would expect from microsoft.

Learn Unix and you will not need to ask why it is a bad idea.

But if you learn unix you will no longer consider MS a software vendor.

If you guys are so smart, write software that doesn't use the registry to store hundreds of application specific settings. I get that you have to use it for some things, just add a config file for your other settings.

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.