45

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?

pnuts
  • 58,317
  • 11
  • 87
  • 139
justadreamer
  • 2,410
  • 2
  • 21
  • 24
  • 21
    I'd be interested in seeing you justify the claim that a filesystem is a more natural way of doing it. – Rob Oct 23 '09 at 22:45
  • 4
    This should be Community Wiki, IMHO – Seb Oct 23 '09 at 23:07
  • 8
    Have you looked under /etc/ on recent linuxes ? I count 2389 files in totat, including subdirs. It's not conherent, not simple, and though some of it might be unserstandable - stuff like sendmail.cf,named.conf,ntp.conf never was perfectly understandable. – nos Oct 23 '09 at 23:27
  • 10
    > Have you looked under /etc on recent linuxes? - Yes I did, have you looked on registry on recent windowses thru some regedit, how many keys and subtrees (meaning and reason of which you obviously don't know) are there? – justadreamer Oct 24 '09 at 19:37

9 Answers9

54
  1. Centralized - which is useful for roaming profiles.
  2. Transactional - which makes it harder to smash your configuration.
  3. Security - You can enforce read/write with better granularity than a file (per-key/value).
Kevin Montrose
  • 22,191
  • 9
  • 88
  • 137
  • 15
    Nice to-the-point summary. – Michael Burr Oct 23 '09 at 22:59
  • 2
    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 Oct 24 '09 at 04:18
  • 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 Oct 24 '09 at 07:17
  • Could you explain what you mean by roaming profiles please? – Edan Maor Oct 24 '09 at 19:31
  • 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 Oct 24 '09 at 19:36
  • 2
    @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 & ~ versus HKLM & HKCU; they're an equivalent division. – Kevin Montrose Oct 24 '09 at 19:53
  • @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 Oct 26 '09 at 19:20
13

This article discusses INI files vs registry: https://devblogs.microsoft.com/oldnewthing/20071126-00/?p=24383.

TripleAccretion
  • 312
  • 3
  • 10
Bastien Léonard
  • 60,478
  • 20
  • 78
  • 95
  • 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 Oct 24 '09 at 19:39
12

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.

JAL
  • 21,295
  • 1
  • 48
  • 66
7
  • 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
  • 39,039
  • 2
  • 53
  • 68
  • 1
    gconfd is just a GUI front-end for plain-text configuration files that live in your home directory. Nice try though. – Vitali Oct 24 '09 at 04:40
  • 4
    regedit is just a GUI front-end for encoded configuration files that live in the system directory. Nice try though. – snicker Oct 24 '09 at 04:53
  • 3
    @Vitali -- Uh. gconf is a bunch of structured key value pairs for configuration data. Just like the registry. – asveikau Oct 24 '09 at 04:55
7

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
  • 40,917
  • 20
  • 104
  • 186
  • 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 Oct 24 '09 at 04:19
  • Good point, Pavel. (The age of the reigstry saves my answer - phew! ;)) – peterchen Oct 24 '09 at 15:37
1

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
  • 254
  • 1
  • 3
  • 8
  • 7
    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 Oct 23 '09 at 22:51
  • @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 ? – Rook Oct 23 '09 at 23:35
  • 3
    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 Oct 24 '09 at 04:15
  • 1
    @PavelMinaev Do you have a link to such recommendation? I'm interested to see all the arguments made as I did not know that (even though I do use config files almost always) – julealgon May 14 '14 at 15:48
  • @peterchen Just to add Program Files (x86), SysWOW64, winsxs, drivers, DriverStore... – IGRACH May 05 '17 at 20:38
1

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
  • 4,021
  • 4
  • 24
  • 27
  • 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. – Rook Oct 23 '09 at 23:33
  • 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 Oct 24 '09 at 04:16
  • Is there a Win32 API or an environment variable for that? I'm curious. – yogman Oct 26 '09 at 17:56
0

For starters, it's quicker to read and write to the registry during the course of a user session.

Rob
  • 47,999
  • 5
  • 74
  • 91
-2

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
  • 5,137
  • 1
  • 18
  • 29
  • 1
    What embedded, fast network database would have been appropriate to use in 1989 on a 386 computer with 12 MB of RAM? – Michael Oct 23 '09 at 23:52
  • @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 Oct 24 '09 at 03:55