Sorry for being 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?
+6
A:
Central, ubiquitous management of program preferences and settings.
Will Hartung
2010-07-25 00:31:04
So that's what it's for... I've always wondered that ;) I'd love to hear someone explain why it's **needed**, though...
no
2010-07-25 00:35:46
+2
A:
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.
no
2010-07-25 00:33:17
-1: sorry, you've just demonstrated your ignorance of the Registry.
John Saunders
2010-07-25 00:35:28
Ok, so then "why can't software just write variables to their own local files?" Enlighten me.
no
2010-07-25 00:37:52
@no: Race conditions, lack of transactional management, lack of security, etc.. Registry is like a database.
0A0D
2010-07-25 00:38:34
-1: @no: See my answer for enlightenment. Personally, I don't like having to learn the specific configuration syntax for every app on my system, but that's just me.
Billy ONeal
2010-07-25 00:39:15
@0A0D - those features could be useful, although I don't see how the security would be any better than normal filesystem security. I'd probably just use an embedded database if I needed features like that.
no
2010-07-25 00:47:23
@no: It allows for much finer control on a per key basis. See here: http://msdn.microsoft.com/en-us/library/ms724878%28VS.85%29.aspx
0A0D
2010-07-25 00:49:00
@no: A LOT. I have worked on large government projects where the ACL settings were very important. This also important with PA-DSS/PCI compliance.
0A0D
2010-07-25 01:02:41
@0A0D - so things are getting stored in the registry that could violate PCI compliance? It just sounds like a crazy design to me. Surely for specific needs like this there is something better than the windows registry to store the data in (like a real database, or encrypted file).
no
2010-07-25 01:30:31
+5
A:
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.
paxdiablo
2010-07-25 00:33:34
Thanks for the answer, why is it slower to read an ini file than from registry? Can't you store local files in a way that are quick to read? And you don't need to read/write much do you, just load it into memory?
Tom Gullen
2010-07-25 02:15:55
Yes, you can store in INI files for quick retrieval but the original INI files were text ones. Hence parsing was needed. It's also possible (I don't know this for sure) that Windows will open the registry files on startup and keep them open so you don't even have to open it - just ask for a key and it'll use database techniques for fast retrieval.
paxdiablo
2010-07-25 04:29:25
+6
A:
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.)
0A0D
2010-07-25 00:33:56
+1
A:
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.
Arafangion
2010-07-25 00:35:07
+10
A:
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.
msw
2010-07-25 00:37:39
+2
A:
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.
Billy ONeal
2010-07-25 00:38:24
Who says they can't use a library to complete steps 1 and 2, and option 3 isn't much different from using the "dangerous" regedit.
Arafangion
2010-07-25 00:42:07
@Arafangion: .NET provides API for accessing the registry very easily (built-in). Plus with the registry, you get transactional management in Windows 7 and Vista. Much more powerful and faster than writing to a file.
0A0D
2010-07-25 00:43:47
1 and 2. Use a library, or a few dirt-simple lines of file io code. 3. Yes, and the format can be something appropriate to the domain of the program. It is only simple from the perspective of a windows programmer using windows APIs. Developers on other platforms writing cross-platform software should find it much more easy and natural to use file storage on every platform.
no
2010-07-25 00:43:56
@no: How is the Application Data directory cross-platform? That is the recommended directory for user files from Microsoft and I am fairly certain it doesn't exist on Linux.
0A0D
2010-07-25 00:45:59
@0A0D: Ah yes, `Application Data`, that's what it's called. I'm rdesktop'd into a windows box now and in there I see Microsoft, MySQL, Subversion, and TortoiseSVN. I've saved settings for my cross-platform programs there too. There's no "Application Data" directory on linux, but the same paradigm exists; the user's home folder contains other folders for each program, and those folders have data stored in them. It's CP if you conditionally #define the folder where you're going to store stuff; on each platform it should be available from an environment variable.
no
2010-07-25 00:53:49
@no: Hmm.. I don't think file parsing is dirt simple. There are several dirt simple ways of doing it wrong... As for being simple if you're writing cross platform to use the filesystem, well duh! Platforms other than windows don't have a registry. That does not mean that those of us writing for "only" 90% of the computers on earth shouldn't be allowed to use useful features of the OS.
Billy ONeal
2010-07-25 01:01:48
@no: Having several defines is not cross platform, but rather ".\MyProgramDirectory" could be.
0A0D
2010-07-25 01:04:03
@0A0D - well, you could do it without `define`... just expand the `APPDATA` and `HOME` env vars and whichever one expands to something, use it. If neither expands, current directory could be used.
no
2010-07-25 01:27:00
Has any of you ever used OS X? It stores preferences Linux style in system or user specific .plist files, which are either compressed binary or XML files. There's a dead simply API to read from and write to these files, so their format is even standardized. The best of both worlds, it's possible. Oh, and the Plist Editor that comes with the system is actually dead simple and usable, so even a normal user can edit these files without problem.
deceze
2010-07-25 01:40:13
@deceze: Really? Does it support transactions, DACLs, and remove editing? The registry does.
Billy ONeal
2010-07-25 01:57:11
@Billy AFAIK the mentioned API handles transactions. DACLs can be implemented by writing to separate .plist files with different permissions. That's arguably slightly less convenient, but a lot simpler and less error prone. Remote(?) editing is provided by a service that sits on top of the registry anyway, the registry itself is not inherently remote editable. There's no reason this couldn't exist with .plist files, but AFAIK is doesn't. Probably because it's not really used all that often.
deceze
2010-07-25 02:27:38
@deceze: The nice part about the registry is that it is centralized.. plist files go with each and every application and are not centralized. Major downside of the registry is that it can and does get corrupted, halting system startup. plist files are also binary files as of OS X 10.4 so they are not intuitively human editable without a special utility.
0A0D
2010-07-25 03:13:00
@0A0D .plist files are centrally stored in the `~/Library/Preferences/` or `/Library/Preferences/` directories for user and system-wide settings respectively. They are manipulatable via a command line utility, an API and an excellent GUI app. They're easy to copy and delete. You can create one in plain text without specialized tools. Even if they're not editable in binary format without a tool, that's already better than what the registry can claim. It's intrinsically harder to make a decent editor for the registry, since it's inherently much more complex. RegEdit.exe vs. Plist Editor, q.e.d.
deceze
2010-07-25 04:59:05
+10
A:
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.
Jay
2010-07-25 01:32:54
Except that application ought not to have write-rights in their own directory. But there is the AppData folder and the like so yea, the registry is mostly obsolete nowadays.
mafutrct
2010-09-17 08:54:42
mafutrct: Hmm, I generally think it makes a lot of sense to write your config or preferences file in the same directory with your executable. What's the harm? You're afraid the program will hack itself? I can see logic to having different app data directories for each user, that Windows idea isn't totally insane. What do you see as the issue there?
Jay
2010-09-17 13:48:32