Hi, this is more OS architecture question than programming directly, but still. Why was the Windows registry created as a completely separate subsystem for storing system/application settings? In *nix OS'es there is /etc directory which is perfectly understandable, as filesystem is a natural hierarchical way for storing settings, while Microsoft decided to create a completely outside hierarchical subsystem, which seems to be a foolish investment, why didn't they just use a filesystem hierarchy?
+11
A:
This article discusses INI files vs registry: http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx
Bastien Léonard
2009-10-23 22:42:35
Thank you, very nice article. And there it is really proved why registry is much much better than ini files. However /etc concept + user-specific settings in home directories under *nix is much wider concept than old ini files.
justadreamer
2009-10-24 19:39:13
A:
For starters, it's quicker to read and write to the registry during the course of a user session.
Rob
2009-10-23 22:43:38
A:
The idea is to have all settings for all programs stored in one single place instead of having them spread all over your disk.
Gabb0
2009-10-23 22:44:56
Likely true for it's initial design, only that microsoft failed to think of that when they designed Program Files, Common Program Files, User Home Directory, User App Data, User Local App Data and All Users App Data. No critique, just one of my old gripes.
peterchen
2009-10-23 22:51:22
@peterchen - no, no. you do have a point. although, i admit, maybe it was how it was initially thought, then over the course of history necessities forced to take other things into consideration ... but, as i said in comment to @yogman, why not use the unix principle of config files of different priorities ?
ldigas
2009-10-23 23:35:03
In fact, Windows best practices today strongly recommend against storing settings in the registry - you're supposed to be using config files (preferably human readable, please) for that. Leave the registry for OS settings, file associations, and COM components.
Pavel Minaev
2009-10-24 04:15:48
+4
A:
- Each application doesn't have to reinvent a config file format
- You can easily use the registry in kernel mode code
As mentioned in the Old New Thing article cited by Bastien:
- The system can handle concurrency issues for you
- You can ACL registry keys
I would also mention that many *nix frameworks have reinvented the registry... Like gconfd on GNOME.
asveikau
2009-10-23 22:46:24
gconfd is just a GUI front-end for plain-text configuration files that live in your home directory. Nice try though.
Vitali
2009-10-24 04:40:00
regedit is just a GUI front-end for encoded configuration files that live in the system directory. Nice try though.
snicker
2009-10-24 04:53:49
@Vitali -- Uh. gconf is a bunch of structured key value pairs for configuration data. Just like the registry.
asveikau
2009-10-24 04:55:22
+30
A:
- Centralized - which is useful for roaming profiles.
- Transactional - which makes it harder to smash your configuration.
- Security - You can enforce read/write with better granularity than a file (per-key/value).
Kevin Montrose
2009-10-23 22:47:44
What's transactional about registry? Do you mean that individual value updates are atomic? Or do you mean Vista's Transactional Registry (which is quite obviously a very recent development)? Also, of course, one can have per-key/value ACL with files if each value is a separate file (I recall there was some Linux registry-like thingy from IBM that actually did it that way...).
Pavel Minaev
2009-10-24 04:18:10
Individual updates are transacted - this has been the case since NT 3.1. Unlike flat files where updates require a read/alter/write sequence that can potentially corrupt the file.
Larry Osterman
2009-10-24 07:17:12
Centralized - /etc is also centralized (and is owned by root by default unless you set different perms on some subdirectories)Transactional - hm..., filesystem write operations are also transactional for modern filesystems I believe - and robustness is very important, I've never seen /etc beeing corrupt, while I saw saw windows registry get corrupted quite frequently.Security/granularity - this is surely a disadvantage of /etc. However it is also simpler to have common settings in /etc while user preferences are stored in user homedirectories.
justadreamer
2009-10-24 19:36:01
@justadreamer: /etc is centralized, but the state of many apps pre-registry was to drop config files into "."; the registry is an alternative. File systems provide transactions at the file level at best (and not all filesystems in use do); which means to update a configuration file transactionally you have to store the whole thing in memory - you can't update a single key as a transaction. It is not simpler by any definition to store things in /etc they're an equivalent division.
Kevin Montrose
2009-10-24 19:53:14
@Edan Maor: Its something businesses, schools, and other large organizations make use of. Basically, within a domain, it lets you log onto any number of machines and have your documents and settings "follow" you. For example, your Firefox extensions (provided they are per-user friendly) or Word settings would be the same on all machines. Part of roaming profiles is storing per-user registry settings in a central location so they can be downloaded when you log into a new machine. [I'm playing kind of loose with defintions here, I'd be greatful if somehow who knows more would clarify]
Kevin Montrose
2009-10-26 19:20:04
+7
A:
Also, file system granularity: one cluster for each value is a bit to much, so you need to make a tradeoff where the file system ends and the settings file starts. That of course doesn't give you a consistent API. So why not pull all settings into a few key files, and give you a consistent API to access it? BAM - registry.
(And since MS generally considers API more importantthan format, it's no surprise the files are opaque)
[Raymond Chen voice]Remember, it was designed for computers where 4MB of RAM was plenty.[/Raymond Chen voice]
peterchen
2009-10-23 22:50:00
You won't get one cluster per value on any modern filesystem that knows how to pack small file streams directly in allocation table. NTFS does that; see http://en.wikipedia.org/wiki/Ntfs#Resident_vs._non-resident_data_streams
Pavel Minaev
2009-10-24 04:19:43
Good point, Pavel. (The age of the reigstry saves my answer - phew! ;))
peterchen
2009-10-24 15:37:32
A:
They did it, I believe, to support a separate setting for each login user. In Unix, there's a concept of home directory, while none in Windows.
yogman
2009-10-23 22:59:57
Not completely true ... why not use a scheme, for example, like vim does ... vimfiles from higher ranking directory gets loaded (admin specified), them vimfiles from lower ranking directory gets loaded (user specified) overwriting if necessary the previous one ... the question is why does the registry need to be loaded as a whole, and not for separate programs.
ldigas
2009-10-23 23:33:11
There is a concept of a user home directory in Windows (so long as we're speaking about NT). On a single-user OS, like Win9x was, it's not relevant anyway.
Pavel Minaev
2009-10-24 04:16:31
A:
It created a single point entry for the entire system's application configuration control. It would have been a nice usecase for an embedded network database (e.g. Raima used by Rational) or a text database (Bernstein's cdb).
srini.venigalla
2009-10-23 23:09:14
What embedded, fast network database would have been appropriate to use in 1989 on a 386 computer with 12 MB of RAM?
Michael
2009-10-23 23:52:33
@Michael: If the interface and implementation are separated, the underlying structure could have been easily replaced with an embedded database. In any case, for argument's sake, I am sure both Raima and cdb were available in 89, in DOS.
srini.venigalla
2009-10-24 03:55:04
+2
A:
So that when the binary registry gets corrupted, you'll just give up and go buy the newest version of windows for a fresh install.
Alex JL
2009-10-24 04:15:10