Every time I run into the Registry, it’s to try to disentangle the changes made by a recent installation of some software. When the Registry is reverted to a prior edition, the recent changes all disappear.
Since tying all software together seems like asking for trouble, I wonder why nearly all programs do so.
What is it that they get out of putting their data into such a morass? I know it’s not required, because several of my favorite programs simply keep their settings in a unique .ini file.
I’m more of a generalist than a systems analyst, but I’ll give it a shot. I’m assuming you’re talking about the Windows Registry, and thus about Windows PCs and not Macs – I don’t know jack about Mac OS.
Windows tries to make things run more smoothly by making everything a part of it. It doesn’t merely run programs, it incorporates them into the OS. When everything is hunky-dory and there are no conflicts between drivers, IRQs, and the like, performance is improved.
the unfortunate truth of the matter is that the hunky-dory, no-conflicts arrangement is impossible to achieve outside the lab. With so many different hardware and software vendors contributing to every PC and program, all of them doing their thing a little differently, incompatibilities are virtually guaranteed. This has the opposite effect intended by the Windows designers – performance plummets and the OS becomes unstable, closing programs for illegal operations and often crashing the system outright.
My experience with Macs is that they crash just as much, but for different reasons. I prefer Windows, but that’s probably because it’s what I learned first after DOS.
I hope that helps. I hope even more that somebody with better information comes along and confirms my statements and goes into more detail.
Simply, the registry is a central database where software applications can store data. The central-ness is key, since all the programs share stuff, so the registry is the place where those sharings take place.
I’m sorry, after previewing, I shouldn’t have said “share data”. It’s not a data repository. I should have said “share configuration information”.
err, “store data” was the phrase I was looking to replace. geez.
I understand a little for interconnected programs, like Word and Outlook, that can call each other.
But even then, they don’t seem to actually accept any of the other programs settings, default fonts and directories, etc.
The situation I find is that described by Cap’n Crude
The registry is, in concept, not a bad idea. Some aspects of the design leave a lot to be desired, but providing a standardized configuration / user preferences database is generally a good thing. It gives you a consistent way to access configuration info, rather than figuring out how each program chose to implement it.
The reason programs use it is because it is a service which the Windows SDK makes available to you, so programmers make use of the service to avoid having to fiddle about writing their own config file. And to be “good citizens”, since most Windows programming classes will teach you that it’s the proper thing to do. Another virtue of it is that since it is being managed by Windows, the data can be cached beyond the life of your program, saving some file access.
Let’s say I want to keep track of a few things for a hypothetical program, like the last playlist in an mp3 “jukebox”, so I can restore that when you bring the program back up. I could decide on a file format, and write my own routine to read/write the file, be sure I flush that info out to the config file on all the various flavors of program exit, and explicitly read in the file and decode the information from my pet format when the program starts up. A lot easier to simply create a key in the registry, stuff the playlist info in there every time it changes, and let Windows manage it. And that’s what the registry is supposed to be FOR, after all.
One problem you have with any centralized facility is namespace discipline, and Windows is traditionally bad in this area. The programmer may pretty much construct any heirarchical key they like, and there are very few guidelines. The registry could benefit from stricter rules regarding use of the available namespace, a less klutzy tree structure, and making aliases within that structure more obvious.
I’m not sure why people find the registry so terrifying. It is simply a set of heirarchical keys which the programmer may access and add to, to store information in. It deserves to be treated carefully, since it IS a centralized facility, but it isn’t that hard to grasp. You should NOT do wholesale import/export of the registry unless you are really desparate, or really know what you are doing. If you are going to write in it with regedit, you should try to find the little area you really want to remove or change. Fortunately, most commercial vendors are pretty good about staking out their specific sections of the registry using their company and product names.
This guy seems to have written a fairly decent tutorial:
I kind of like the decenterilized approach. If one thing F’s up it won’t f’ up everything else. If I uninstall something and an ini file is floating around - it may take up HD space but that’s about it but leave too many frgments in hte registry and windows will slow down. (or that’s how I understand it)
Cap’n Crude:
The OP isn’t talking about Macs, as the MacOS doesn’t HAVE a registry.
Another primary reason, besides being able to store application specific data, was to limit the number of duplicate system files installed on your computer. For instance the file mfc42.dll contains the code need to draw windows and buttons and all the neat little widgets. Programmers use this library in their program then ship it along with their program. During the install if Windows notices that you already have that file on your system, maybe from another application, it will simply use the one already there instead of copying the new one onto the system. Versioning becomes an issue, though. For instance, what if Programmer A uses version 1.0 of that file, but Programmer B uses version 1.1? By default, Windows will install the new one and no one is the wiser. And since version 1.1 has everything version 1.0 (plus more) had there is no problem with Program A. The probelm comes in when a you install a program that uses an older version. By default, Windows is supposed to not install the older version, or at the very least tell you waht the program is trying to do. Unfortunately, this can be overridden by the programmer. Now applcations that relied on services new to version 1.1 will fail. This is refered to as DLL Hell. The next version of Windows (XP) will solve this by allowing both versions to be present on the system at the same time.
I did like your explanation about how it saves programming, since I can see where that would make a company want to “be a good citizen”. So that, plus all the others’ information above does answer my main question. Thanks.
The question you asked-
My answer is like k2dave said. One error, from any program, even one that loaded itself when you hit some web .wav link, brings down the entire system, and often in very strange ways.
And the only “solution”, reverting to a prior version of the registry makes little sense to me. The program that has screwed things up may have self-installed itself last month, and not put into full execution until today, exposing its error. My backups were all made automatically and erased automatically by these programs, so I now have no way of knowing what was a good version and what was a bad one. If I want to go back one month, I can’t because nobody saved that version. Even if they had, I would still lose all the hundreds of settings various programs have made in the meantime.
Ok, I think its time for a little more clarification from someone with professional background.
There are, in the realm of typical third-party software, two different sorts of registry changes that will be made as a result of installation. If the software controls a specific hardware device, there may be more for the device driver itself (this can differ depending on whether you run 9x/NT).
The first kind of change, is what has already been talked about, which are the addition of keys, subkeys and values that store configuration information for the specific application. This should usually be found under HKEY_CURRENT_USER\Software<Vendor Name><Product Name>
It can also be found under HKEY_LOCAL_MACHINE… - entries that are specific to a user profile (for example, most recent file access) typically go under HKEY_CURRENT_USER, and settings specific to the (you guessed it!) machine, go in HKEY_LOCAL_MACHINE. Pretty nifty.
These entries are absolutely harmless. The only way they could ever, ever cause you a problem is if you had different versions of the same program on the same machine.
So what is the problem? One problem, a very old problem, is DLL Hell. DLL hell is the problem where common libraries are stored in the system folder, where they can be efficiently shared. The problem is that sometimes new versions are introduced with a new program that are incompatible with existing software. Generally it is not an interface incompatability as much as it is a practical incompatibility - the new version exposes a bug in older software.
COM made this worse in many ways. Used to be, you could keep copy of all your DLLs in the directory with your program, and be sure that they would be safe. Well, COM classes have to be registered, in the registry. This is so a program can instantiate a COM object without having to know what DLL it is implemented in, or anything specific about the DLL. This is important for a lot of reasons of theoretical purity, but the practical result was registry hell, which is truly not any different than the old DLL hell. New installations, even though they might have put their COM dlls in their directory, when they registered them it forced every program on the computer to begin using that COM dll.
There are many documented problems of these types. One major one we are struggling with at work currently is that certain LDAP functions do not work with ADO 2.5 (a database API library used by most modern software that uses DB) installed unless the Microsoft Active Directory Client is also installed. Since we have programs that require ADO 2.5, we cannot install ADO 2.1 (which works fine). Our only option is to roll-out Windows 2000 or the MSADC (which is probably what we will do).
This is a gross oversimplification, and I don’t want to say that every problem you’ve ever experienced is due to COM hell. There is also plenty of device driver hell, but I’m not very experienced with that side of things so I’ll let others elaborate if they wish.
In conclusion: registry good for program settings. COM bad.
Just a couple more notes:
You should not generally do replacements of the registry, and people often muck with it when they don’t need to. If you ARE going to mess with it, you should be doing surgery on it with regedit, not mass import of a previous version.
Most software vendors are actually pretty good about staking out areas for themselves keyed by their company and product names. You will find that most vendors stick specific stuff for their programs under HKEY_CURRENT_USER/Software/<company name> or HKEY_LOCAL_MACHINE/SOFTWARE/<company name>.
It will also help you to know that programs may get themselves started at boot or login time by registering in:
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Run and similar things, like “RunOnce”
or similar keys in HKEY_CURRENT_USER.
This is where you will find a lot of those things that insist on bringing themselves up at boot time which are not in your startup folder.
It’s a sign that something went wrong that an end user is mucking with the registry in the first place, other than out of interest. I think a lot of stuff that people blame on the registry - “I installed A and now B doesn’t work” - is actually misinstallation of DLL versions, like JamesCarroll is alluding to. The way dynamic libraries work on windows is a joke perpetrated by somebody with an absolutely rotten sense of humor.
Also, if you’ve migrated to W2000 from 98 or 95, be aware that things can install themselves as services, too. You might want to look at the “services” control panel and familiarize yourself with it.
And yes, if it were being developed today, it would probably be stored as an XML document. I have to believe someone at MS is suggesting migrating it.
Anyway, you might go ahead and bring up regedit sometime and walk around the heirarchy to help you see what’s going on. You might do this in conjunction with that guy’s tutorial I posted. It’s fairly easy to avoid changing anything - if you inadvertantly double-click on a value, you will get a separate “edit <foo>” dialog box that you can cancel. If you wish, you can examine everything by staying strictly on the tree control in the left hand pane. From there, the only way you can affect anything is to explicitly use menu items like “delete” or “rename”. Do be aware that regedit does not have an “undo”, though, and edits the “live” registry on the fly (design decisions which I might question).
Alternatively, you could export the whole registry and examine the text file to familiarize yourself with what’s in there.
I simulposted with Cooper. I agree - COM bad. And he thinks I don’t have a professional background? :).
(note the very rare smily use)
I can see my statement could be read a couple different ways - I meant more clarification by someone else with a professional background - your first post didn’t talk about the different sort of things that go into the registry, or explain the hierarchy.
Obviously though, GMTA.