What is the terminology for describing the various parts of the registry?

Hives, keys, values, types, and data.

As I noted some years ago, the file that holds the registry data is called a hive.

A hive contains a tree of keys.

Keys contain a list of values.

Associated with each value is a type and data.

The terminology is weird and counter-intuitive thanks to the history of the registry. Back in the days before named values, you queried the data associated with (the default value of) a key by calling RegQueryValue, which was a rather natural name since it matches the key/value pattern. But the introduction of named values threw this pattern into disarray. Perhaps a better name could have been chosen for what today are known as values and data, but what's done is done and that's the name we're stuck with.

I'm sorry.

"Raymond, you idiot" section:

"Sure, Raymond, that's the historical reason why the terminology is messed up, but why hasn't anybody fixed it in the meantime?"

Well, changing terminology at this point would probably create even more confusion. For example, suppose you decide that the terminology should be changed as follows:

Old New
key node
subkey subnode
value key
type type
data value

I agree with you that this terminology would probably be much less confusing, but how do you get there from here? When you update all the documentation to change the terminology, how do you know that you covered everything? Do you grep for the word key everywhere and then decide on a case-by-case whether it should be changed to node? That's probably some hundreds of thousands of hits just inside the MSDN Library. (Even worse with value, type, and data.) And then there are all the comments in source code that are now wrong. And all the magazine articles written prior to the change are now wrong; who's going to go update them? And the existing source code needs to change HKEY to HNODE and RegOpenKey to RegOpenNode. Okay, so maybe you leave the old names around for compatibility, but now you have the problem that RegOpenKey returns a node, not a key, and that you pass a key name to RegQueryValueEx, and what the heck does RegDeleteKey do? Does it delete an old-key or a new-key?

Bonus chatter: There's also this thing called a class. I have no idea what it's for, so don't ask.

Comments (23)
  1. John says:

    As far as I can tell, the "class" is not used at all.  I suspect it is just a piece of data that is tagged onto the key and Windows does nothing with it.  I’ve never used it or seen anyone else use it.  It must have been used at some point; anyone have documentation from the 16-bit days?

  2. Stewart says:


    From the current docs for RegCreateKey the 16 bit registry didn’t have "class", so it must have been added in Win32 for some reason. The mystery deepens.

  3. John says:

    Wow, that’s interesting; didn’t expect that at all.  Perhaps it was in the Win95 beta along with the Shell Folders key (http://blogs.msdn.com/oldnewthing/archive/2003/11/03/55532.aspx), destined to be trapped in the API forever due to backward compatibility concerns.

  4. Stewart says:

    I always thought it was older than that – maybe something from the early days of NT that never got used in public. The kernel mode NT registry API (ZwCreateKey) is more or less the same as the user mode API and also has the class parameter, which suggests (to me at least) the 32bit registry API started life in NT.

    MSDN says that the class parameter "is used by the configuration manager" whatever that is.

  5. Anonymous says:

    What are HKLM/HKCU/etc. called? The registry doesn’t directly reflect the hive > keys > subkeys > values structure, so these "keys" are not actually contained in the hives.

  6. John says:

    Well, you have to start from somewhere; I guess you could call them root keys or something ("C:" is referred to as a root directory).  A root key would point to the top of the key hierarchy in a given hive, although there is not strictly a 1-to-1 mapping of root keys to hives; but I guess that’s an implementation detail.  Then you have dynamic things like HKEY_PERFORMANCE_DATA which aren’t backed by a hive at all.

  7. Mark says:

    Anonymous: they’re predefined keys (http://msdn.microsoft.com/en-us/library/ms724836%28VS.85%29.aspx).  Hives are really "mountable" trees.

  8. Mark says:

    To clarify: the registry you see as a program only exists in memory.  The HKEY_LOCAL_MACHINE key is not represented on disk, but allows subtrees to be added that are effectively reparse points.  Similarly, HKEY_CLASSES_ROOT is a combination of HKEY_CURRENT_USERSoftwareClasses and HKEY_LOCAL_MACHINESoftwareClasses.

  9. Anonymous says:

    Obviously, the solution is to have disjoint sets of terms for the "new" and the "old" terms. Having the same term in both just invites confusion, but with a disjoint set you only need a glossary ("node" = "key", "value" = "thingy"…)

  10. Mark says:

    One last note: my guess is someone thought developers would want a special key type (like lpType for values), perhaps for storing simple objects.  It looks like it was introduced with CreateKeyEx in NT 3.1.

    It works – you can store and retrieve it, and it will export happily into a hive.  It’s just not visible in any UI.

  11. dave says:

    It’s a ‘hive’ because the content is organized as a bee-tree, right?

  12. MadQ says:

    Just because I had nothing better to do I decided to write a little app that finds all the registry keys having that have a class length greater that zero.

    Several thousand keys have a class of "REG_SZ" or "class". I’m guessing that these are just cases of "I’ll just pass something that seems valid, just in case."

    It looks to me like subkeys of HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa use the class to store various calculated values.

    And then there’s online gaming and copy protection Application X that seems to use the class to hide things it doesn’t want the user to see.

    Okay, that was mildly amusing. Now what should I do? [queue Jungle Book vultures scene: http://www.youtube.com/watch?v=MGTWmrnPdgk ]

  13. John says:

    Cool.  I did the same and found a few others.

    "cygnus" for keys relating to Cygwin.

    "WinZip Application Data" for keys relating to WinZip.

    "VS7" for some keys relating to Visual Studio.

    "Shell" for keys under CurrentVersionExplorerFileExts.

    "DefaultClass" for various keys.

    A lot of odds and ends for other keys.

    I don’t know what the point of it is, though.  Perhaps some internal bookkeeping for the various applications.

  14. Jonathan says:

    Associated with each value is a type and data.

    And a name, no?

    I used to think that a registry value had "value name" and "value value". Kind of like the story about the dogs family: Father dog, mother dog, son dog, daughter dog and dog dog.

    And I definitely agree about the terminology change. Terms are immutable – once you’ve coined a term, you can never ever change it. You can only make up new ones.

  15. steveg says:

    So… if you were wanted to store something in the registry that’s hard to find then class data is just about perfect. <laugh type="nefarious" />

  16. DCMonkey says:

    From a 1996 usenet post:

    This question came up on Compuserve, and the Microsoft answer was, "Er, we thought we had a use for it, but we didn’t, so leave it blank."


  17. M. Barrett says:

    The clinker in the system is "value," which in the registry plays the role of an additional level of key, when we expect it to be a datum.

    Replace "value" by "field" and leave the other terms alone. This would remove the confusion, and the changes to documentation and software required should be minimal compared to what you discuss.

  18. Alexandre Grigoriev says:


    No, it’s because it gives you hives.

  19. Worf says:

    Windows CE .net (4.0 Talisker) introduced hive-based registry for the first time – before that it was RAM-based, and persisting it was a fun exercise to do in the kernel (you get a binary blob you dump into nonvolatile storage…).

    At least with hives, we put the main one on flash disk, and the kernel has a tiny boot hive. Hilarity ensues if vital keys are missing from the boot hive…

  20. Danl65 says:

    To add to the confusion I could swear I read in one book where individual keys were referred to as a ‘leaf’, although the name of the book escapes me at this time.

  21. Dave says:

    Didn’t Windows 95 officially change directories to folders? Is that an example of a name change that was followed through?

    Any idea why that was made?

  22. Mark says:

    Danl65: standard terminology for trees.  You have root, inner, and leaf nodes.  You can alternatively get trunks and branches if the tree isn’t node-based (as in CVS).

    Of course there’s always someone who takes metaphors to the extreme, like http://computerperformance.co.uk/vista/vista_registry_vbscript.htm


  23. Gregory Kong says:

    Indeed, although I believe that the term ‘folder’ in Windows is more all-encompassing than the concept of the filesystem ‘directory’. For instance, Control Panel (and sub-items within), as well as others, are ‘system folders’ that do not necessarily reside anywhere within the filesystem.

    In any event, I still call them directories, when they reside on disks.

Comments are closed.

Skip to main content