Honestly, the registry as an idea is a great concept - structured, typed data to define the configuration of an entire system, which all applications use for config? Remind anyone of YAML loaded into K8s?
The Registry sounds like a great concept but it's the worst architectural decision Microsoft ever made for Windows.
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.
> The Registry is the reason why you need an installer instead of being able to drop application files into a directory and run them.
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.
If an application is storing 'private' data that it doesn't expect to be modified by humans or any other application, then storing a struct straight into the registry seems appropriate.
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.
It's still nasty. Structs are brittle. They aren't easy to inspect when doing some forensics on a bug. It makes it harder to extend the program when you are fussing with version number fields and multiple formats.
INI or JSON or something can make life a lot easier, at least in high level GCed languages.
> 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.
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 minority of programs actually do the latter, and it’s not about the OS but about the fact that the program was designed to be reliant on the registry.
Of course it is the fault of program, but as design registry is thought to be always there, self-evident, so it is partially the problem. It encourages to rely on it totally.
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.
“Registry cleaners” have been irrelevant for 2 decades, and have been a sure sign of a scam for most of that time. Even in the '90s, the main thing they did was exporting the whole tree into one giant text file, then deleting/moving the old database and importing the dump into a fresh copy in DOS shell before system boot (reg.exe was/is a combined DOS+Windows executable). You could do the same manually. The size difference could be significant because file allocation scheme was not good enough, and slowly inflated it with use.
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.
I recall when a Linux kernel dev broke it down like 1) files can be slow and correct, 2) or files can be fast and incorrect, 3) but if you want fast and correct, you need a database. Slashdot and other tabloids reported this as "Linux developer says Linux needs a Registry". (In the meanwhile a lot of devs have come around with sqlite.)
>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.
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.
Would you say that a database is 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"?
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
My unpopular opinion is that there are a lot of times a database should not be used, and the rest of the time, a standalone database is still a bad idea if you don't need it.
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.
At around the turn of the millennium, I ported a COM object from Windows to Linux. I made everything required work, from cruft DllMain and DllCanUnloadNow to
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.
The main problem with the Windows Registry, is that it doesn't clean up after itself... Programs are unlikely to fully purge their settings, and even Windows leaves detritus everywhere (just look in the USB enumeration keys - EVERYTHING you've ever plugged in to USB is still listed there).
>The Registry cannot be documented.
>Configuration files can be individually versioned and managed.
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.
A .reg file is to the Registry as a diff or release point is to an initialisation file. .reg files aren't the Registry, they're ways to save or set Registry values.
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.
Swapping out config files can have unintended consequences for running service instances.
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.
How are you going to point multiple services at multiple different registries at the same time? Because absent full system virtualisation, you cannot.
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.
The concept of the registry is just fine. The implementation had a few small architectural issues, but throwing out the concept because of a single specific implementation is a mistake.
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.
Windows has had 'restore points' for the registry since forever which are auto-created every time an application is installed. Prior to that the system came with backup/restore tools. They're even mentioned on the Wikipedia page.
And I've seen too many non-functional W10 systems with a corrupt registry. AFAIK, Windows used to make automatic backups of the registry that you could restore from, but they stopped doing that several years ago. I don't care what Wikipedia says. It's a shitshow and a brittle system with an absurd single point of failure.
I've seen it once during a few years as a campus tech support for about 10,000 people.
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.
Logical errors in the registry AFAIK. Maybe it's a broken hive file that wasn't cleanly written and closed. Who knows. It's not like Windows is particularly transparent about registry issues.
I think OP has a machine misbehaving and is thinking "probably a registry problem" in the same way you'd say "probably something wrong in /etc" on Linux.
> The Registry sounds like a great concept but it's the worst architectural decision Microsoft ever made for Windows.
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.
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.
> The Registry sounds like a great concept but it's the worst architectural decision Microsoft ever made for Windows.
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.
> 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.
> lpClass most likely is a class name in COM/OLE sense.
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.)
I implemented a registry once, where plugins in an app could store data. It was kind of horrific.
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.
It is a great concept, it makes sense from any reasonable viewpoint, yet for some reason I loath the registry with a passion, not exactly sure why, but I think it comes down to the question.
Why do we need an additional tree to store configuration?
I think because it’s used haphazardly and applications make messes that they never clean up.
Also, having both env vars, local config and registry creates sort of a smorgasbord-stuff gets thrown everywhere.
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.
I agree 100%, I’m just hypothesising why it could have ended up like that, and if there’s a way to have something “registry-like” without the observed flaws.
I always just found it incredibly hostile to access and use. Hate to think the hours I've lost from my life using Regedit.
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.
You don't. You can store it anywhere else you like and most programs do. The system uses it to store its own configuration so other programs can configure the way they integrate with the system.
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)
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.
At some point MSDN replaced the names in comments with email addresses associated with accounts. My email address wasn't public but all of a sudden it was, at Microsoft's discretion! I complained about this, potentially this was the data concern they had, because it was actually pretty dumb on their part.
Backwards compatibility. I'm not remotely kidding here. There are still programs that directly parse these files instead of using Windows' APIs and the format itself is fragile, and in the 90's the concern was more of disk speed access (where commentswill slow down reading of registry files) meant that the designer have opted to not put comments (as you expect from that time that the manual is literally a book or a separate CHM or TXT file, with user comments stored at the "Notes" part of the book or another separate TXT file). It's similar to the binary DOC format pre-Word 97 which includes actual C pointers (so it's less of a document format and more of a snapshot of Microsoft Word memory).
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).
This has sort of existed since Windows NT 4.0 days in the form of Administrative Templates, with the newer "ADMX" format shipping with Windows Vista / Server 2008:
Human interaction with JS kinda sucks regardless. It's a good lowest common denominator of data, that is somewhat decent for hand editing when needed.
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.
Because you can’t automatically manage a configuration database that has comments. If the applications can remove and recreate their registry values and keys there is no way to keep comments associated with these things.
This idea is also the recommended workaround for JSON, and it is equally wrong there. For one thing, then you can only comment the key/folder/object, not the individual value.
> Because the registry is a database. Why would you put comments in a database?
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.
Oracle has user/all/dba_tab_comments and user/all/dba_col_comments.
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.
Ms SQL has extended properties, particularly the ms_description one that is exposed in ssms. But that's comments on database columns and objects, not data points.
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.
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.
The HKEY_CURRENT_USER key is just an alias within the same DB, it points to some key under HKEY_USERS. I don't think this counts as another instance of the DB, despite stored in separate files.
ESENT databases are independent: a database used by Windows search doesn't share anything with the DB used by windows update or Zune music.
The user registries are in those ntuser.dat files. The registry tree is like the Unix filesystem, the system mounts subtrees at specific locations. So the ntuser.dat files get mounted in HKEY_USERS.
There are also magic aliases like HKEY_CURRENT_USER and (mostly system managed) links like CurrentControlSet.
> do you consider a Unix root a single file system?
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.
I wish I'd thought of that! I used to work with someone who was unbearable and he also hated butterflies. I should have snuck as many butterfly references in the code as I could.
In reality, instead of trolling this guy... I just left the team so I didn't have to work with him anymore. Which is the correct, mature, professional thing to do.
But my inner child still likes to dream. As far as revenge fantasies go, it's pretty tame, don't you think?
I had a feeling this was going to be a Raymond Chen post. Loved reading the Old New Thing back in the day. Amazingly it looks like it is still going strong.
No it isn't; the hive metaphor entirely fits the Windows Registry, which is a kind of hornet's nest where configuration goes to disappear.
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.
seems like you didn't read the actual article. it's short enough to include here.
"""
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.
"""
I read it several hours before writing that comment.
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.
