Why is a registry file called a “hive”? (2003)
devblogs.microsoft.com
devblogs.microsoft.com
Why do we need an additional tree to store configuration?
If all you were allowed for config was the registry,and application scopes were more tightly defined and enforced, it would probably be a lot nicer.
But that goes for all sysadmin stuff in Windows. Give me plain text files I can grep and edit with vim, backup by making copies, diff, version etc. Make it JSON if you want but let me use real tools and not the horror show of Regedit and it's ilk.
The idea was to move away from text based ini files, which is previously how Windows apps were configured. At the time I thought "awesome".
However the registry is just a black box full of binary garbage, chewing gum and rubber bands that tightly couples everything in Windows.and it's like spaghetti and can't possibly be unwound.
.ini files were a much better idea, in hindsight.
I've always wished Microsoft would have the courage to somehow get rid of the registry but I don't think it will ever happen.
I feel like Windows needs a clean start that implements its modern APIs, ditches its commitment to backward compatibility, gets rid of the registry, and makes everything including the UI consistent and modular. That's a Windows worth getting excited about.
The unix model of plain text files for configuration is a much better idea than a Registry.
Without the Registry there wouldn't be the concept of "Registry cleaners" https://en.wikipedia.org/wiki/Registry_cleaner <--- read this link to get a sense of all the bad things about the Registry.
The Registry is the reason why you need an installer instead of being able to drop application files into a directory and run them.
There was a Windows machine that was struggling to complete boot or otherwise just wouldn't get to a functional state. Windows itself knew something was wrong but was unable to fix it.
I ran a live cd, removed the "live" registry file, and let the system automatically revert to the backup version of the registry it had right there. Problem solved, perfect system up and running.
Configuration files can be.
Configuration files can be individually versioned and managed.
Configuration files can exist in multiple instances, be swapped out or referenced for a specific invocation.
I could go on.
Yes, the Registry is an absolute disaster.
So can registry files - just write them as .reg files (which can be automatically exported or trivially handwritten in standard ASCII syntax). Anything that starts with a semicolon is a comment.
If you want in-place documentation just go create a string value wherever you want with whatever content you want.
>Configuration files can exist in multiple instances, be swapped out or referenced for a specific invocation.
Again, use .reg files and the tooling for this is trivial.
https://support.microsoft.com/en-us/topic/how-to-add-modify-...
This works well and is deployed at scale in all sorts of organizations for all sorts of projects.
https://support.google.com/chrome/a/answer/9131254?hl=en#zip...
There remains only one registry. Much software reflects present values.
It's not possible to have multiple simultaneous Registry keys, and swapping in or out additional keys may very well produce unwanted or unintended consequences for running service instances.
If I want to fire up some specific version of a process or server on, say, Linux, I can generally (specifics vary, but these are typical):
- Pass along arguments as command-line parameters.
- Set environment variables with desired values.
- Specify both global (system-wide) and user-specific configurations.
- Enable or disable specific configuration files using invocation flags.
- And if all else fails, jail the process and launch within a filesystem context in which the desired configuration file(s) exist.
Again: the Registry affords none of this.
Let alone comments, as previously noted.
Reg files are functionally equivalent to config files. Instead of `cp foo.conf.bak foo.conf`, just `reg import foo.bak.reg`
Windows processes take command-line parameters and environment variables. None of your points are specific to configuration files - or to Linux. There are even third party jail equivalents for Windows that include registry jailing.
I don't have to copy config.001 to config. I can simply point the process to config.001.
There might be many such of those configs. (This can of course become ... too much of a good thing. But that's simply because it's so easy to do and get carried away with.)
The remainer are far more difficult or error prone under Registry.
You can drop a program into a directory and run it. If you want it to integrate with the OS or DE, you need an installer to configure it in the centralized location. No difference there between Windows and Linux.
Furthermore, the specific aspect of it you reference (that it is binary instead of textual) has almost nothing to do with the problems you say are caused by it (that install scripts need to add keys to it, or that obsolete keys are retained and third party scripts clean them up with heuristics). None of that would change if it was INI. A binary configuration format has nothing to do with the architecture of what it is used to configure.
If it was truly a terrible decision then they would surely have not recreated it with Windows Phone, which had no win32 components that would have depended on it and no win32 API compatibility at all. But they did.
I suspect the reason non-Windows people don't like it is just that it is a pure expression of Microsoft's API-oriented (as opposed to file-oriented) approach to Windows, which does not mesh with the *nix mindset.
GP most likely means REG_BINARY littered over the place which usually means the application in question is dumping some struct into the registry.
It's the same as the application making a temp file to store some random state.
Except a registry entry is probably more efficient for something that's under a kilobyte typically.
INI or JSON or something can make life a lot easier, at least in high level GCed languages.
This applies only for minority of the programs. There are many programs which simply refuse to work or crashes because some entry is missing from the registry.
The registry is intended to be used for interacting with system configuration or for system wide settings. E.G. registering a new file extension or a URI scheme.
It’s not an application data store that’s what appdata is there for.
A version of Windows that can’t run most of my favourite programs and games is something I definitely wouldn’t be excited about. If I wanted a computer that can run no software that I care about I would buy a Mac.
http://reboot.pro/index.php?showtopic=7681
and multi-commander has a plugin for this (though this is more like representing the registry as a filesystem):
http://multicommander.com/docs/browse-registry
As I see it the Registry format has many common points/similarities to NTFS, it is somehow a cross between a filesystem and a database or can be "seen" as either.
Previous post/discussion with some more links:
How program stored its own data made little difference. It could be a configuration file, it could be a designated place in registry — as long as nothing else touched it, everything was fine. The core problem was with the system configuration files. Each program, old and new, had to understand all kinds of entries that could be added there by each other, and that included would-be future versions. Given something like
[ZZZ386]
...
DRIVER=MSSTD.SYS,EXTRA.SYS
...
every programmer had to know that there could be more than one driver (not really obvious if all common machines around you worked with single standard one), that comma was a delimiter, that the order could be important (and therefore you couldn't always add your entry to the end). But they didn't expect any of it, so programs broke themselves, or silently broke other programs. Registry was introduced as a system-wide black box with a strict API. That allowed correctness and security checks (at least on NT), adding compatibility hooks for specific programs, and so on.
However, it was not a sandbox of any kind. Any change in system configuration that affects more than just your program would still require installer and uninstaller logic. You probably imagine something similar to external manifest files that would hold, say, program-related CLSIDs. Now imagine that enumerating CLSIDs requires enumerating all manifest files in the system… #8-0
I suspect it has been explained more thoroughly somewhere on the same linked blog.
Is that the Coding Horror smiley?
The idea is great, the problem is with the implementation. You can’t have a configuration database so central to your system and then implement it using a fragile database engine that breaks itself all the time.
CoCreateInstance and whatnot. The COM object configured itself using the Registry, so I ported all the API functions. I wrote equivalents that worked with a text-based representation. It was great: the code thought it was using the real registry, but you could go in there with "grep -r" and your editor to muck around in it.
HKEY_LOCAL_MACHINE mapped under /etc, HKEY_CURRENT_USER under $HOME/.whatever type of thing.
I don't delete old emails in my inbox, yet life goes on and it isn't an issue. Occasionally having that old stuff is helpful.
I think the problem wasn't so much the idea itself, it is just that the implementation left a lot to be desired. A better implementation of the same idea could have been much more successful.
The registry could have come with a schema, whereby each key has a class defining what values it is allowed to have. I think Microsoft may have actually had some plans to do that, because every registry key has a "class" (lpClass parameter of RegCreateKeyExW) – however, few registry keys have the class field set, and almost no software pays any attention to it – suggesting that whatever Microsoft was planning with respect to a registry schema never came to pass. There could have been a "schema hive" containing class/attribute definitions, and then any attempt to set a key/value on a schema-enforced key would be validated against the schema hive.
If keys had an enforced schema, the registry could be self-documenting – the class and attribute definitions could have a "description" value explaining what each is for. I suppose Microsoft couldn't force third parties to write meaningful descriptions, but they could have set a positive example. They could also have had a tool to auto-generate schema documentation (in HTML or RTF or whatever) from the descriptions in the registry schema.
They could have implemented something like a "foreign key" – a link type which will not let you delete the target while other keys have values pointing to it. (Not the existing REG_LINK which is much more limited; REG_SMART_LINK maybe?) This would likely need some kind of "backlink" index for fast retrieval of back-references. Maybe each key could have a "virtual attribute" which contains a list (REG_SMART_LINK_LIST) of backlinks. The schema could specify what are the allowed target types for any link attribute.
They could have a package database in the registry, and enforce that every registry key is owned by a package. Uninstalling a package automatically removes all the keys it owns.
They could have shipped with an IFS which exposes the registry as a pseudo-filesystem, which would have made it easier to manipulate. (Cygwin kind of does this with /proc/registry, and PowerShell has something similar, but it would have been better as a proper filesystem which appears like any other.)
It could even expose the registry data as JSON or XML files, dynamically generated at runtime. \\registry\HKEY_LOCAL_MACHINE\Foo\Bar\Baz\__REGDATA__.json could be a JSON file containing the values of the HKEY_LOCAL_MACHINE\Foo\Bar\Baz registry key. If you write to that file, it could parse the JSON you write and update the values appropriately.
> The unix model of plain text files for configuration is a much better idea than a Registry.
I actually don't like that model. You end up with text files littered all over the place. Automating configuration is a mess because every app has a different config syntax. It is a flawed model too, just with a different set of flaws.
> The Registry is the reason why you need an installer instead of being able to drop application files into a directory and run them.
Not really. An application can be designed to not require any registry keys, and so if all its registry keys are missing it just uses sensible defaults. Or an application can be defined to check for its required keys at every startup and create them if they are missing.
Microsoft could have defined a way for an application to embed a small registry hive in its EXE. When launching the EXE, it would check if those keys exist in the registry, and automatically load them.
In Microsoft's defence, the Registry was designed in the early 1990s (it first shipped in Windows 3.1 in 1992), and a lot of the ideas I am proposing may have had too high a performance cost for the limited machines of the early 1990s, or relied on technologies or ideas which people hadn't thought of yet.
— A lot of WIN32.HLP articles from the 3.x to 9x transition era talk about “registration database”, which seems to be the original name for registry.
https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Arch...
https://docs.microsoft.com/en-us/cpp/mfc/registration?view=m...
> RegEdit merges the contents of the .reg text file into the registration database.
— HKEY_CLASSES_ROOT is the lowest defined numerical constant, maybe it was the first one.
— RegSetValue() only handles REG_SZ (string) values.
— REG_SZ is the default format for new and empty registry keys.
— System data about components stored in {CLSID} branches all use short REG_SZ values for everything: numbers, lists ("8,PBrush"). This is in line with handling such values in INI files, short string “verbs” and class names in ShellExecuteEx() (notice that the registry key can be used to define an object class — was it initially supposed that any registry key corresponded to some class in some hierarchy?), text messages in DDE, etc.
— Finally, Wikipedia (ooh) says that the registry started as component registration database. So maybe the point of lpClass was tagging the branches that belonged to this or that class, or preventing components from messing with each other's data…
I believe that some team created a nice, compact, and simple enough storage solution to hold a predictable amount of text values under first and third party CLSID keys to be used in system COM libraries operation. It was way better than some potentially enormous OLE.INI which would regularly fail to be written completely in case of power loss, among other problems. Then it was found to be so nice that upper management decided to use it for everything, and the team cursed, and tore their hair, but it was too late.
It is possible that articles in computer journals introducing COM/OLE in Windows 3 have more information on first approach to registry and its goals back then.
I don't think that is true. In the original Windows 3.1 registry, lpClass did not exist. You only had the RegCreateKey() function which had no lpClass parameter, that parameter was added in RegCreateKeyEx() which was only in NT (and later Windows 95 too).
COM/OLE never used lpClass. Out-of-the-box, very few Windows registry keys have lpClass set, and those that do it is mostly some meaningless value like "Shell" or "Setup", which COM/OLE completely ignores. The one place (that I know of) which it is (or was) actually used, is to store the syskey encryption key [0]. I think using lpClass for that is just abusing it for a bit of security-by-obscurity, it is a way to store data in the registry but hide it from most registry tools (which provide no access to lpClass because almost nobody uses it.) Possibly other people are doing the same thing (to store license keys, detect expiration of trial periods, malware hiding stuff, etc.)
Text files have MORE problems, not less. Your familiarity with them and your unfamiliarity with the registry doesn't make text files better, it makes them more familiar. Similarly, even if you know the Windows Registry well, that's the Windows-specific implementation that dates back to the 1990s!
If the registry concept was re-done today, with all of the lessons learnt across decades of software pattern evolution, it would be done differently.
What you probably don't realise is that Registry provides an awful lot that prevents every developer having to reinvent in a Unique and Special Way that is incompatible with everything else.
It gets "right" the following:
- Hierarchical storage of key/value data.
- A single consistent GUI and API across all application settings.
- Permissions on a per folder path and/or per key basis.
- Integrated audit logging for all access, including both read and write access, down to the individual key level.
- Binary (byte array) data stored natively.
- Strong typing for 32-bit and 64-bit integers.
- Special string types such as "substitute environment variables in this string" vs "just a plain string".
- Layering of settings. E.g.: Machine, User, Default, etc...
- Integration with the Group Policy engine, where there are "policy enforced" and "default preferences" that can be pushed out centrally.
That last one needs expanding, because Linux has NOTHING like it, and alternatives don't even come close. The policy engine is declarative, with a "template" file specifying the keys and allowed values. This has matching multi-lingual files so that administrators that don't speak English can see the names and multi-paragraph descriptions in their native language. The policy settings apply and un-apply in layers automatically. Moving locations can automatically deploy a setting, and then wind it back if you return to your original location. Thousands of settings can be centrally administered by one admin for tens of thousands of machines with a few mouse clicks. Linux config files are a single layer and are effectively write-only. You can't read them with an API or merge/unmerge changes on the fly. There is just no way to solve this problem with general text-files.
If I were to reinvent registry files now, in 2022, I would just fix a few implementation specific annoyances:
- More strong types. E.g.: network addresses, DNS names, GUIDs, etc...
- The "layering" of Group Policy is manually implemented in app code, so most apps outside of the Enterprise space don't have policy integration. I would make the policy settings automatically overlap the same key names so that they're merged by the "registry engine" instead of the app.
- Writing arbitrary values into a single share hive is a mistake. I would create a hive-per-application.
- Requiring kernel transitions for registry key reads is also a mistake. The "user" hives belonging to individual applications ought to be accessed directly by the associated app processes. I've seen hacks that implement this using API rewrites that improve the performance of some business applications by 20-40%!
- Registry hives should have "layers" much like Docker files in the physical sense, not just the logical sense. So for example an application patch would be a new delta layer over the base layer, but then policy would always layer on top of the latest patch, whatever that may be.
- Stronger tooling for developers. Make policy template files trivial to create. The template files should auto-generate matching strongly typed configuration objects in multiple languages, and these should also integrate with CLI command parsers, environment variable overrides, etc...
- Use a more standard base storage format, such as SQLite.
- Make it cross-platform and open-source.
- Similarly, the policy engine shouldn't be so closely tied to a single product (Active Directory), but should be a pluggable module that large-scale enterprise software can also reuse as an internal component. Think Citrix, Anti-Virus products, Backup, etc... anything that needs to manage hundreds of servers from a console with policy, preferences, etc...
Layered settings are nice, but nothing you can't do with files, and a well defined file structure(/etc/app/myapp, /etc/policy/myapp, .config/app/myapp, etc)
GUIs are great, but nothing you can't do with a settings.ini.uidefinition file(Or better yet, settings.d/uidefinition.json), and an editor.
The registry GUI is currently not really much better than a text file , modern settings GUIs are context sensitive wizards with live changes and all kinds of stuff.
More strong types could possibly improve that, if GUIs supported all of them, but you probably couldn't cover everything or fully compete with in-app settings.
Maybe with some kind of embedded HTML/JS form definition for every hive.
Linux does have dconf, which seems to solve most registry use cases.
I don't think you would, that's not the conventional wisdom. Databases are considered to be the epitomy of clean, reliable, and efficient representations of data. It is text files that lack these capabilities and are considered a non-standard mess when it comes to data.
The registry is just a database. It may have not seen the best usage it could have from windows and applications, does that make it a bad architectural decision? Would we think different on the registry if it was just SQLite (or would we in this case think differently of SQLite)? Personally I firmly believe that the registry approach is a great architectural decision, for all the reasons outlined here: https://sqlite.org/appfileformat.html
Text can be versioned.
And databases invariably need either manual admin or a docker container or something. Many apps could totally be easy, instant app store type things, but they depend on some extra daemon. More things to misconfigure.
DBs are usually secured by passwords. Now I need a strong password... on a completely local system, instead of just some file permissions?
SQlite is absolutely wonderful. Possibly one if the best libraries ever made. But text is perfect for configuration.
Apps don't need to do queries against config. They don't frequently make small updates of the type one usually wants a DB for(Unless they are horribly written and rewrite megabytes files every minute even with no changes like browsers do or used to do).
Config isn't high performance, storage space isn't critical, but you do often want to version.
Text files are great for config because you can version them and they tend to be somewhat self documenting. And with no registry you can use very useful patterns like one file per object.
One of Linux's nastiest things, that is mostly fixed now, was things like hosts files and fstab, individual files responsible for multiple objects that are likely to be "owned" by different packages. Now most things have a config.d folder or something so you can use multiple files.
Registries take away the ability to represent things using the file hierarchy and manipulate it with common tools.
This is a blatant lie, I know posts on Old New Thing with zero comments have been extremely rare. And of course:
https://web.archive.org/web/20091231092140/http://blogs.msdn...
Note that pingbacks were also available, and some posts had quite a lot of them from various years, creating a web of somehow related pieces of information. After 2012 the comments were loaded with AJAX, its endpoint obviously stopped existing, and it wouldn't work on Web Archive anyway. However, these resurfaced in 2016 after another move. And someone on bytepointer.com has created a sane static copy which deserves an applause.
Also, various old custom text style markup was broken in other posts, but it's a general problem with all MSDN content. People doing the conversion just didn't care. I guess informing them that some old knowledge base articles were actually distributed as self-extracting archives (IIRC, in custom format, so you have to run them in an emulator to unpack) with text and code files (in DOS code page, with occasional pseudographics) would make them panic and run away.
So there's a corporation the size of Microsoft, and one of the most highly regarded places to set “correct” approach to Windows programming, and the most they can offer to Raymond Chen is “Hey, old man, our engine supports bold and italic, and comments from Microsoft® Account™ logins, you can import your posts and fix them manually. Next!” The announce post had an excuse (personal data protection laws)
https://devblogs.microsoft.com/oldnewthing/20190313-01/?p=10...
HOWEVER, it does not cover pingbacks (at least pingbacks from oldnewthing to oldnewthing itself). Also, even in 2003 we see the remains of “old” old comment system, so at least some comments had been impossible to delete all along even before the move. Tsk.
/grumble
Oh wow, nice, thanks for mentioning that. I've been grumbling about the lost comments, too…
Comments would be nice, but they'd get lost in loading and dumping.
Moving beyond pure hierarchy, and having first class ordering, where comments are real data objects that survive import would probably be the way to go.
Something like slightly less verbose XML might be a great thing.
Regedit is a table editor of that database. So again, would you insert random records into a database as comments?
Now if you're asking "why aren't there comments in .REG files" the answer is there are, prefix it with a semicolon (not well documented):
https://docs.microsoft.com/en-us/previous-versions/windows/e...
Probably wouldn't have been difficult to guess though, since they follow the .INI file syntax (which ironically is now used by SystemD)
A database stores whatever data is necessary for the application. If comments for application records are needed, that includes comments.
A self-documenting registry where applications registered user information about keys that they used (whether or not the application populated them) as well as apps populating data for keys, so that navigating to a key in the UI would provide you with the documentation from any app or apps concerned with that key as well as the ability to review and edit the data value would be awesome.
The only places in my legacy databases where these are populated emerged from the Erwin data modeler. We are lazy in not populating them with new tables.
I wonder if SQLite has something similar.
Which highlights the difference between the registry and an rdbms. In an rdbms you can absolutely comment the columns and tables, just not the rows and individual data points.
In the registry, the data isn't tabular. Every data point has a corresponding field name. That name absolutely would support a comment in sql.
Edit: Some have noted Group Policy and its note field. I've disqualified that because it's not readily available in Home versions of Windows, because third-party applications are often not bundled with the necessary ADM/ADMX files necessary (which you might also want to comment), and the fact that the parent commenter disqualified the text-based REG files (which supports comments).
https://docs.microsoft.com/en-us/previous-versions/windows/d...
These databases are NoSQL as well. Albeit somewhat closer to traditional SQL than the registry: ESENT databases are made of B-trees, have column schema, primary/secondary indices, and support transactions. Unlike SQL servers, ESENT doesn’t have relations across tables, doesn’t have a query language (instead it has a low-level API to move cursors), and doesn’t support remote nor inter-process access, a DB is exclusive to a single process.
This is clearly false, how could you store user-specific data? (Hint: it's the NTUSER.DAT on each of the users' directory.) Additionally, you could create binary registry files and load them, funnily in much the same manner as how would mount drives on Unix and Unix-derived/inspired systems. Unless you consider that as a single root, the comparison that "Windows only has 1 registry" (which is wrong since that system-wide registry is backed up every boot and shutdown) is silly.
ESENT databases are independent: a database used by Windows search doesn't share anything with the DB used by windows update or Zune music.
Also, you've just ignored the whole line about loading custom registry files.
No idea. On Windows, I consider volume a single file system.
> you've just ignored the whole line about loading custom registry files
I know about them. If you really want multiple instances of the registry, you can also use virtual machines with guest Windows OS.
Still, 99% of Windows users don't do any of that. But their OS runs several programs like Windows search indexer which create and use ESENT databases. That's why I consider ESENT to be the most deployed NoSQL DB.
There are also magic aliases like HKEY_CURRENT_USER and (mostly system managed) links like CurrentControlSet.
You know who you are!
But my inner child still likes to dream. As far as revenge fantasies go, it's pretty tame, don't you think?
His blog is full of nice reads
The person who came up with that was developing it seriously, and the naming almost certainly had to have "buy in" from other "stakeholders" in the project.
""" Because one of the original developers of Windows NT hated bees. So the developer who was responsible for the registry snuck in as many bee references as he could. A registry file is called a “hive”, and registry data are stored in “cells”, which is what honeycombs are made of. """
Regardless of the motivation for the naming having come from tormenting bee-hating guy, the naming had to make sense. The developer in question would probably not have gotten away trying to call a registry root "fiddlestick". He had a boss, and peers, and they signed off on "hive".
Perhaps that person had some creative name for the entire thing instead of "The Registry" (Apiary? Ha!), which perhaps had been overruled. The "Hive" jargon is not really end-user-facing, though.
a generation of people getting to grips with NT in the 90s will disagree with you on your last point, too.
(Hint: use a search engine.)