What's the point of a system registry?_问答_开发者

Sorry for b开发者_开发百科eing really ignorant here, I just want to learn, why is the registry needed for programs? What's it for and why can't software just write variables to their own local files? Does it do something I'm not aware of?

IMHO, the Windows Registry is an invention almost as practical and useful as the pet rock.

By putting application configuration data in the same place with operating system configuration data, it makes any attempt to update an app carry the danger of screwing up the operating system. It's like making a single remote control that controls both your television and your pacemaker. Sure, you could argue that it's convenient to have all the controls in one place, but it also creates the danger that any attempt to change the channel will kill you.
The old INI files were easy to read and update by both computers and humans. For the truly lazy programmer who couldn't figure out how to manipulate a simple text file, there were library functions to do it simply and easily. The registry is mildly difficult to update with a program, and extremely difficult for any human being to read, especially a non-programmer.
In the bad old days when each program had a directory and stored all its data in that directory, you could delete a program by simply deleting the directory, and you could confidently back up a program by simply copying this directory. With the registry, you need a special uninstall program for each program, and it is common to have obsolete or junk entries float around in the registry indefinately.

Is there anyone out there who can say with a straight face that the registry is easy to manage, or that it increases the reliability of the system?

What I think Microsoft should have done was create a central file that recorded the directory where each app is installed and the extensions of files that it knows how to open. That should be the only information the OS needs to know about an app. Everything else should be stored in the app's own directory.

Update: Reply to Mick

I disagree with most of the points in the referenced article. Like, "You can't store binary data in an INI file" and "INI files only have two levels of structure". If the system INI file stored only the info the OS needs to know about apps, that's just a few text strings each, there's no need for binary data or a hierarchical structure. An application INI should just hold config and preference information, and thus, again, no need for binary data and hierarchies. The advantage of the INI format was that it was a simple, readable, text file. That made it easy to parse, easy to update, and easy to manage. The whole point of my original post was that by adding the registry, with all sorts of complex features, Microsoft replaced something that was easy to manage with something that was hard to manage.

There's some validity to the points about security and concurrency. But surely we could have solved those problems within the existing framework.

Sure, an INI file does not make a good database. But so what? That isn't what it was for. This is like complaining that a pair of shoes doesn't help you swim or enable you to fly or cook your breakfast, and therefore we should replace all shoes with jet-powered flippers with radio controls and built-in microwave ovens. The result would surely be an overly-complicated, awkward monstrosity. It would cease to be comfortable to walk in, and would probably not be very good for swimming or making breakfast. Instead of being very good for one thing -- walking -- it would be barely usable for a dozen things. Things that, by the way, we already had perfectly good tools to accomplish. Oh, kind of like the registry.

The Windows Registry was intended to stem the proliferation of local .ini files that programs were writing.

It has been well argued that the particular implementation was far worse than the problem it set out to cure. Having had to do precision surgery on a registry or two in my life, I happen to agree.

Registry Purpose

The Windows Registry is a hierarchical database that stores configuration settings and options on Microsoft Windows operating systems. It contains settings for low-level operating system components as well as the applications running on the platform: the kernel, device drivers, services, SAM, user interface and third party applications all make use of the Registry. The registry also provides a means to access counters for profiling system performance.

Why Registry over INI files?

.INI files stored each program's user settings in a separate file. By contrast, the Windows registry stores all application settings in one central repository and in a standardized form. This offers several advantages over INI files.[2] Since accessing the registry does not require parsing, it may be read from or written to more quickly than an INI file. As well, strongly-typed data can be stored in the registry, as opposed to the text information stored in INI files. Because user-based registry settings are loaded from a user-specific path rather than from a read-only system location, the registry allows multiple users to share the same machine, and also allows programs to work for a least-privilege user. Backup and restoration is also simplified as the registry can be accessed over a network connection for remote management/support, including from scripts, using the standard set of APIs, as long as the Remote Registry service is running and firewall rules permit this.

The registry has features that improve system integrity, as the registry is constructed as a database and offers database-like features such as atomic updates. If two processes attempt to update the same registry value at the same time, one process's change will precede the other's and the overall consistency of the data will be maintained. Where changes are made to INI files, such race conditions can result in inconsistent data which doesn't match either attempted update. Windows Vista and Windows 7 provide transactional updates to the registry, extending the atomicity guarantees across multiple key and/or value changes, with traditional commit-abort semantics. (Note however that NTFS provides such support for the file system as well, so the same guarantees could, in theory, be obtained with traditional configuration files.)

From Wikipedia - Windows Registry

Central, ubiquitous management of program preferences and settings.

Actually, that was the way it was done in Windows 3.1, with many applications using their own INI files. Windows 95 (from memory) introduced the concept of a centralised repository (though I think there was a limited purpose registry before then) and people have been buying registry cleaner programs ever since.

People used to complain then that there were too many INI files to manage and that speed was a problem since they were text files that needed parsing. I, for one, prefer applications to have their own stuff in their own directories so as to make clean-up easier when you want to delete them.

Quoted verbatim from wikipedia:

When first introduced with Windows 3.1, the Windows registry's primary purpose was to store configuration information for COM-based components. With the introduction of Windows 95 and Windows NT, its use was extended to tidy up the profusion of per-program INI files that had previously been used to store configuration settings for Windows programs.

http://en.wikipedia.org/wiki/Windows_Registry

Why can't software just write variables to their own local files?

It can, but this can be inconvenient for the software developer, because:

The developer must write their own parser.
The developer must write their own serialization logic.
Users who want to edit options manually must learn the syntax of that given configuration file.

The registry is nothing more than a simple (from a programmer's prospective) database.

It's just a silly convention. In a unix or mac filesystem the software does exactly what you suggest, writing its settings in normal files, usually organized in hidden folders in the user's home directory. Windows has something similar, a folder called "Application Data" off of each user's home folder, and your program can use that for storage instead of screwing with windows APIs and the registry.

Because the Windows NT team thought it was a good way to address the problems with using INI files. This was the primary way that applications (and Windows itself) stored their settings in early versions of Windows: by just "writing variables to their own local files."

We've now come almost full circle with XML configuration files, thanks in large part to application vendors' misbehavior with regards to the registry and the inherent likelihood (obvious now in retrospect) of a monolithic database becoming slowly corrupted over time. Although to be fair, most modern criticisms of the registry forget or simply gloss over the compromises that had to be made for performance reasons at the expense of scalability on those early Windows machines.