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'