15 ms·

I really appreciate when people use technical facts to criticize something, like with this. It is a well written take-down of the implementation of the Windows

I really appreciate when people use technical facts to criticize something, like with this. It is a well written take-down of the implementation of the Windows Registry as of both today and 2010. I suspect if the concept of the registry was created today it would look more like a database (e.g. Sqlite), although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a database engine that supports such a layout. The Registry's Key-Value pairs are 1:1 with a database table's column-values pairs, it is just the multiple tiers of organizing "folders" above that that are a difficult implementation detail. The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. The problem is that everyone invented their own configuration format to store configuration data in /etc and there's no format agnostic API to access that information (you can open it, but can you understand it?). Both UNIX and Windows suffer from the same orphan issue wherein information can be written, the application removed, and it is unsafe to ever remove it since you may not know the author and or all consumers.

bluetomcat 4y ago
> The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". Every application comes up with its own format. Parsing that file is application-specific. Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that has survived in time because text files are still text files.
- arsome 4y ago
  To be fair, Microsoft doesn't rely on the registry for complex configurations either, even IIS uses .config files.
  - justsomehnguy 4y ago
    > even IIS uses .config files. Except that is for serving from a single file share ir a replicated site across a farm of IISes. This has nothing with 'complex configurations'
  - layer8 4y ago
    You can’t look at HKEY_CLASSES_ROOT and claim with a straight face it’s not complex, and it’s a central piece to how a lot of things work in Windows.
    - JonathonW 4y ago
      HKCR has a lot of entries, but the data underneath those entries isn't particularly complex. Its only really big misstep (apart from the fundamental issues with the registry in general) is that file associations and COM registrations are all intermingled in the same namespace. But those can be and are interconnected (see how the Office file types handle their registrations, for example), so it's kind of understandable how they ended up where they did.
      - layer8 4y ago
        The semantics of those entries and their possible subkeys is exceedingly complex. It started out reasonably simple, but features upon features were added with each Windows release, in addition to the application-specific behaviors.
- jabbany 4y ago
  Modern Linux DEs have an arguably worse version by not only having traditional `/etc` for some types of configurations but _also_ having a "registry" that's really similar to the Windows one for GUI apps... (re: gconf for Gnome)
  - xattt 4y ago
    Is Gconf any different from OSX defaults?
  - marcosdumay 4y ago
    "Most" here means the one DE that had a Windows fan rewrite its entire config engine with the only goal of being like Windows. An action that created quite a lot of problems soon after the change.
- qsort 4y ago
  Is there any "way" at all that doesn't suck though? Not having "a way" in this sense is more like a feature, a single source of truth works well if it really is treated as such by all actors. Configurations under unix are a mixture of stdin, config files, env variables and bespoke solutions. Under Windows, you have all of the above and on top of that the registry. Any attempt at a solution in this regard risks being a rerun of the notorious xkcd: 14 ways to specify configurations -> this should satisfy everyone -> 15 ways to specify configurations.
  - bluetomcat 4y ago
    On a more philosophical level, the Unix convention is the "liberal" one, giving application writers more freedoms. Liberty enables more flexible applications and more chaos at the same time. A highly structured approach might be beneficial in the short run, but it might prove to be burdening beyond its due date.
    - tfigment 4y ago
      Its partly about where burden is placed. Making it easy for developers sometimes makes it hard on users and admins. And some times it becomes security issue because of varied approaches. Not sure there is right answer especially in open source where its hard to get devs.
    - trevorishere 4y ago
      Application writers are free to use which ever format they choose on Windows, as well. The Registry is just yet another option -- Microsoft does not force developers to use it. I don't see the Unix convention as the more "liberal" one, here. It typically has _one less_ option.
      - nomel 4y ago
        > The Registry is just yet another option It's not just "another option". It's a system standard option that exists, and can be easily accessed programmatically. There's no equivalent in Unix, since there is no standard, and whatever is available will depend on the distribution. "Here's a built in option, but do whatever" is very different than "do whatever!".
- stockerta 4y ago
  I hate this fanatical love of the UNIX way. I really hate that as of today Windows is the only non UNIX OS. I trully believe that this fact set us back. No more exciting new OSes only boring unix.
  - daxvena 4y ago
    I get where you're coming from, but I think the biggest pro for the "UNIX way" is that text on a filesystem extremely accessible. You don't need a specialized tool to read & modify configuration, you just need a text editor. And while there's no standard for how the data is structured, it's usually pretty easy to figure it out from context. I think it's also really easy to underestimate all the tooling built around text. As soon as you try out some other way, you loose out on version control, diffing, grepping, and a whole bunch of other general tools built for text. I think the only way to get around this is to build generalized tools for working with binary data as a data structure. The problem with this approach is that now you need to maintain a database that describes every possible binary format, where text editors only really have to concern themselves with ASCII & unicode to be useful for most cases.
    - guhidalg 4y ago
      Windows and macOS dominate because 99.9% of users do not care about the difference between registries, file systems, text or binary tools, UNIX-like, POSIX, etc… none of these things matter to them! They just want to use a computer and get on with their life. If you lament this as a programmer, build applications that only work on your OS of choice, make them so good or take a dependency on a feature not available with macOS or Windows so that it can’t be ported, and then you can show the world the light of the UNIX mentality or whatever.
      - mhink 4y ago
        > Windows and macOS dominate because 99.9% of users do not care about the difference between registries, file systems, text or binary tools, UNIX-like, POSIX, etc… none of these things matter to them! They just want to use a computer and get on with their life. The flip side of this argument is that the experience of using computers for that 99.9% of users sucks. As software engineers, it's almost our responsibility to argue in favor of better platforms, because every day not spent fighting the platform is a day we could be building better experiences for our users. (Not to mention, every day the platform doesn't inadvertently mess up the user experience is a day of smaller support costs.)
- lelanthran 4y ago
  > Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". So? The registry doesn't have much of a way either - the actual fields are simply a loose convention. > Every application comes up with its own format. Same with Windows applications - one application might store an IP address as a dotted-octet string, another might store it as a single 32 bit integer. > Parsing that file is application-specific. Same for Windows applications; the subtree for any application is very specific to that application and almost always differs from the subtree for other applications. > Updating a value in a text file means re-writing the whole file again. Not a problem, when it means that breaking a value in a text file breaks only that one application. Break the registry almost always breaks something else, if not the entire system. I'm not saying files in /etc aren't without their problems, I'm saying that all /etc problems are already present in the registry, but the registry adds a few more of its own.
  - jbverschoor 4y ago
    I can’t and shouldn’t be able to write to /etc as an ordinary or guest user. Er-readying values isn’t done usually with apps. You can get corrupted files if two instances fight for the same file. If that’s your thing, please use mongo. Also, please provide support to all the users. Lastly, if you messed up certain configuration or data files, your system won’t boot either on ANY system. Sounds like you’re just one of many anti-windows people, exactly what was pointed out about people bashing the registry.
    - lelanthran 4y ago
      > I can’t and shouldn’t be able to write to /etc as an ordinary or guest user I don't believe you can. What distribution is this?
    - jbverschoor 4y ago
      Point about /etc is that it’s just one part of “configuration”. There’s no /etc for users. That’s why we get all these dot.dirs. At least some apps use ~/.config/
- indymike 4y ago
  > Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that has survived in time because text files are still text files. It always seems like registries are trying to solve three different problems: configuration, status and process shared state. Registries seem to work poorly compared to text files for configuration, and work somewhat well for some level of shared state. I think to compare functionality with Linux, you would have to compare /etc, .configs and the /proc filesystem. As for tecnically inferior, the *ix approach seems to have made the right tradeoffs, via the hand of Darwin, rather than some brilliant engineering insight. The article did a good job of explaining what's wrong with Windows' implementation of the registry. What is right with the *ix approach is that configuration files are usually read on startup, and only written to when configuration is changed (which should be infrequent). This works really well for server software, command line utilities, and an awful lot of GUI software. For some GUI software, particularly where you have really complex feature sets, we need to save state of widgets (i.e. saving the default zoom level) and text files may be problematic for this (i.e two instances of the app running), and this is where the registry really shines.
  - mikepurvis 4y ago
    The biggest issue with etc is that it's owned by root and therefore read only from the application's point of view. So, a great fit for sysadmin-managed configuration, not so great for applications that are GUI-configurable. You end up with a tiered approach of defaults in lib, and cascaded overrides in etc and var.
    - ElectricalUnion 4y ago
      Most Linux GUI apps either litter your home folder with dotfiles, dotfolders (both disgusting) or they follow XDG Base Directory specifications and place configurations in ${XDG_CONFIG_HOME:-${HOME}/.config}
      - dklodh 4y ago
        Most don't even know of XDG. The reason is, there's no central documentation or route for the userland. By Linux, we understand, the kernel and to the kernel developers, that is true. So let alone the anarchy of the userland be handled by distributions and users.
- flohofwoe 4y ago
  I would actually be better if most of the data that applications store in the registry would instead live in simple text files in the AppData directory (which shouldn't be hidden by default). The registry should be restricted to Windows configuration data (like file types and their associated programs), and information that needs to be shared between installed applications.
  - WorldMaker 4y ago
    That's been the recommendation since Windows 95. It's easy to suggest and hard to enforce.
- marcodiego 4y ago
  > Unix simply doesn't have a "way" in that regard Yes. Nothing standardized in this area in UNIX/linux-land. We do have FHS, some xdg specifications and the series of configurations options that were born with dconf which resemble windows registry a bit.
- silverlyra 4y ago
  OpenWRT worked around this by creating UCI, its own configuration system that it uses to generate all package-specific configuration files: https://openwrt.org/docs/guide-user/base-system/uci https://openwrt.org/docs/guide-user/base-system/uci Configuration for all supported packages is stored in files under /etc/config in UCI's own text format, and OpenWRT's init scripts generate service-specific config files based on the UCI settings when the service is (re)started. For example, to configure Samba, users don't edit smb.conf directly, they set UCI settings like samba.workgroup, sambashare.path, etc. There's a `uci` command-line utility to read and modify settings, and UCI forms the basis for the OpenWRT web interface. debconf does something similar for Debian packages, though I haven't seen any packages that use debconf to completely supplant vendor configuration formats the way UCI does. https://en.wikipedia.org/wiki/Debian_configuration_system https://en.wikipedia.org/wiki/Debian_configuration_system
- MaxBarraclough 4y ago
  > a loose convention to put text files in "/etc". For user-specific configuration there's also ~, as with ~/.vimrc and ~/.bashrc. Windows has something similar in C:\Users\theuser\AppData. edit And ~/.config/, as others have mentioned.
adrian_b 4y ago
The problem of removing applications together with their configurations is trivially solved in the various Linux-based systems where any software package is installed only inside a private directory. Any files that would be expected to be in shared directories like /usr/bin, /usr/lib or /etc, are replaced by symbolic links. Except for symbolic links, the installation of a package must not change anything outside its private directory. In my opinion this is the only sane way of managing software packages, because otherwise, also on Linux, but especially on Windows, I have wasted far too much time during the years with debugging various problems caused by the installation/uninstallation programs.
- revolvingocelot 4y ago
  >the various Linux-based systems where any software package is installed only inside a private directory Which are these? I assume Qubes OS sidesteps the problem entirely... NixOS?
  - swinglock 4y ago
    NixOS, mostly, but not for application data (/var usually), which is closer to the registry.
- sumtechguy 4y ago
  You can do similar on windows. However, the registry was turned into trying to solve a slightly different issue of roaming users, and centrally managed settings, split by machine and user, and using what became active directory. They started off with OLE and its central store of holding name value pairs in a tree. Basically making the registry do at least 4 different things. Only one of them it does 'ok' (COM/OLE lookups). In practice it became a huge mess because thousands of applications now keep their settings in there and poor cleanup practices like you see. When like 99% of the use cases out there would be perfectly well suited to just using the forever deprecated win32 INI API to manage settings and MS just saying 'put your config files in these places for different effects'. Instead they said 'put it all in the registry'. Looking back at it, it is now 100% clear it was a bad design decision.
Someone 4y ago
> and there's no format agnostic API to access that information (you can open it, but can you understand it?). One of the critiques in this article is that, because you have to know/guess/assume what encoding is used for various strings, there isn’t one for the registry, either. If so, both approaches suffer from that (but Unix a bit more because it tends to store multiple items under a file system ‘key’, while Windows programs rarely store multiple items under a single registry key) I do wonder what RegEdit.exe does here. Does it infer encoding, have a long list of key-to-encoding mappings, or a combination of the two?
- rwmj 4y ago
  I do wonder what RegEdit.exe does here. Does it infer encoding, have a long list of key-to-encoding mappings, or a combination of the two? I did a bit of experimentation on this too and we think it has a heuristic to guess encodings of strings. (Which to be fair isn't a terrible idea - it's very easy and almost entirely reliable to determine if a string is ASCII/UTF-8 or UTF-16LE which are the major encodings found.)
  - magicalhippo 4y ago
    Based on the documentation[1], it seems clear that strings are stored in Unicode (which should be UTF-16LE). If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, and the ANSI version of this function is used (either by explicitly calling RegGetValueA or by not defining UNICODE before including the Windows.h file), this function converts the stored Unicode string to an ANSI string before copying it to the buffer pointed to by pvData. [1]: https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-reggetvaluea#remarks https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf...
    - rwmj 4y ago
      The first thing to know about Microsoft documentation is it's almost always wrong.
      - 4y ago
pram 4y ago
AIX has a registry-like database for configuration called ODM that is like you’re describing.
samanator 4y ago
Maybe there isn't a database engine that explicitly supports file system data structures, but you could implement a filesystem in the application layer using SQLite as a storage mechanism. Here's an example of someone doing that very thing. https://github.com/guardianproject/libsqlfs https://github.com/guardianproject/libsqlfs
- tauroid 4y ago
  For those looking for a more up to date alternative, with a non-hardcoded DB file path, try https://github.com/greenbender/sqlfs https://github.com/greenbender/sqlfs (not affiliated, just had a look in this area a few weeks ago)
dr-detroit 4y ago
TedDoesntTalk 4y ago
Heierarcical databases support the registry format. But they are popular in the 70s?
silvestrov 4y ago
If I was to reimplement it, I would not let any app read the DB directly. Instead I would make an HTTP like interface where you talk to a service that provides the get/set functionality and which always use a text format like an extended JSON with native support for date, int32, etc. This also enabled much easier and better backwards compability as you can specify app-version in the requests, so a version 5 server can respond in version 4 format. With a service it doesn't matter if things are stored as a single sqlite DB or as multiple files.
- gizmo 4y ago
  You can do everything you describe with a regular function call. Introducing an unnecessary service for something as trivial as config management is even worse than the broken Registry status quo.
  - imtringued 4y ago
    In theory all we need is a libconfig with a standardized interface and distro specific implementations. There would be two use cases, storing hierarchical/tree like data aka JSON, YAML, etc and arbitrary graph like data with complex references. The same could be done with the shell. libcli would be called to parse the command line arguments and your program will have an entry point that receives the parsed data. libcli could also be used to produce structured program outputs which then can be fed into applications, possibly skipping the serialisation deserialization steps. Since libcli will have a standard interface each distro can choose their own CLI format or whether they output their data as JSON or CBOR. In both cases the benefit is that the choice of the data storage mechanism has been decoupled from the application.
    - rwmj 4y ago
      Augeas does this already: https://github.com/hercules-team/augeas https://github.com/hercules-team/augeas
- kreco 4y ago
  Is this sarcastic? I mean, the versioning part sounds good, but JSON like request? I do believe people don't know what inefficient/efficient a system can be depending on the data format they are using.
kalleboo 4y ago
I'm a big fan of the macOS method where there's an OS API to manipulate the user defaults (as its called) but they are actually just stored as files in a standardized format (usually XML). You get the pros of the standardization and the pros of user manipulation (like easily deleting the corrupted settings of some app by removing one or two files)
- LexGray 4y ago
  At least that used to be the macOS method. Once Apple moved most of their apps to the cloud there are constantly open databases pushing settings updates from device to device. Things often start breaking these days if you try to fix things through direct file manipulation. With luck you might be able to find the correct terminal commands to disable services and fingers crossed they don't automatically restart themselves before you are done editing.
- pxc 4y ago
  Plasma/KDE has this with the kreadconfig5 and kwriteconfig5 commands, and it uses a simple INI-like format: https://userbase.kde.org/KDE_System_Administration/Configuration_Files https://userbase.kde.org/KDE_System_Administration/Configura... GNOME has the gsettings command for this, which is the equivalent of the `defaults` command in macOS. Many guides still refer users to the `dconf` command, though, which is technically a lower-level tool but basically does the same thing for 99.999% of GNOME installations. (Users/distro-makers can actually choose the storage format on GNOME's case.)
pjmlp 4y ago
What UNIX way? The religious text files scattered everywhere on the FOSS clones? The adoption of registry ideas by GNOME on gconf? The configuration databases used by HP-UX and Aix? The plists used by NeXTSTEP and macOS? The settings per app used on Android (technically UNIX based at its Linux kernel)
- jollybean 4y ago
  Exactly this. Unix is a bit of a mess, at least that's understandable because it's 'open'. MS registry is a bit nutty, it should be refactored in some simple, clean way, which is apparently extremely difficult to do for big companies, especially those that consider 'backwards compatibility' to be 'everything'.
  - pjmlp 4y ago
    You missed the "closed" UNIXes on my comment.
  - dmitriid 4y ago
    > especially those that consider 'backwards compatibility' to be 'everything'. Thank god there are companies that still think about backwards compatibility and are not intent in breaking everything because there's a shiny new thing ... ahem ... "refactoring in some simple clean way"
    - jollybean 4y ago
      Making things clear is not some kind of 'shiny new thing' that the kids are dancing to - it's rational. 'Backwards Focus Absolutism' means we live in a world of stupid cobwebs and terrible design. The Windows Registry is a hack, it was originally designed to do something mundane and simple. It just grew, like a virus.
      - dmitriid 4y ago
        > 'Backwards Focus Absolutism' means we live in a world of stupid cobwebs and terrible design It also means that until ~Windows 7/10 you could run even win3.1-era apps. And you didn't run into situations like "any 32-bit apps no longer work" or "any apps not updated in more than a year will be removed" as we've seen with Apple.
Blikkentrekker 4y ago
> The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. The problem is that everyone invented their own configuration format to store configuration data in /etc and there's no format agnostic API to access that information (you can open it, but can you understand it?). It's an interesting point and it would really be nice if there were some kind of standard, especially a standardized C library within the standard C library for configuration files, but in practice almost all of them are also easily understood `key=value` pairs that only differ by how they denote this. Still, it would be very nice to be able to inspect and modify them by standardized tools but in practice almost any configuration file opened is obvious.
chasil 4y ago
"The format is... endian-specific." Wasn't there a SPARC port of Windows? Did it run on any other big-endian machines? Were the MIPS and POWER ports little-endian? In any case, I can see why Microsoft paid SQLite for a custom set of features.
- rwmj 4y ago
  It's a very good question! There was also an Alpha port (both-endian and 64 bit). I've never seen a SPARC, POWER, MIPS or Alpha Windows registry so I don't know if hivex could decode them.
  - the_why_of_y 4y ago
    Larry Osterman said in 2005: A decision was made VERY long ago that Windows would not be ported to a big-endian processor. https://web.archive.org/web/20190108142751/https://blogs.msdn.microsoft.com/larryosterman/2005/06/07/the-endian-of-windows/ https://web.archive.org/web/20190108142751/https://blogs.msd...
marcosdumay 4y ago
Doing that in a database is easy. You just write your keys on the "/root/path/subpath" format, and search the strings starting with some text. Most database engines have this kind of search heavily optimized. (And the ones that don't cost hundreds of thousands per core, so who cares?) The one thing you lose by using a real database is that filesystems are only locally coherent, while databases try very hard to be globally coherent. If it has heavy access, the database way will lose performance much faster.
- gregmac 4y ago
  Agreed, and displaying this like a tree is then a UI concern. I think you'd get slightly more performance if you were to store "Folder" and "Key" separately -- either three fields or using a parent-child table. You'd be able to index "Folder", and it would make building the tree structure itself easier and more efficient, and looking up all the values in a specific tree simpler.
- cma 4y ago
  You could do the paths in reverse (root last), to speed up any string comparisons, since prefix almost always matches and is maybe more wasted work the other way.
throw0101a 4y ago
> I suspect if the concept of the registry was created today it would look more like a database (e.g. Sqlite), although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a database engine that supports such a layout. (Open)LDAP uses a hierarchical structure and saves its data in a database: * https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Databa... * https://www.openldap.org/software/man.cgi?query=slapd-mdb https://www.openldap.org/software/man.cgi?query=slapd-mdb
AtNightWeCode 4y ago
There is nothing wrong with a kv hierarchy for config. Used in more modern tools as well like Consul. The problem here is the poor implementation and naive security considerations. Today, there is no broadly used file system that can replace any of this. The difference in performance is just too big.
NonNefarious 4y ago
key/value pairs
debevv 4y ago
The concept of a system-wide hierarchical key-value store is actually very useful is some environments. I had to develop one some time ago [1] for an embedded system, since is super useful to have a single point of truth/configuration/state, if every application agrees on using it (which is the case in such systems were every application is known in advance and developed in house) [1] https://github.com/debevv/camellia https://github.com/debevv/camellia
- rwmj 4y ago
  Xen (the hypervisor) had a thing called XenStore which was a system-wide key-value store with triggers: https://wiki.xenproject.org/wiki/XenStore https://wiki.xenproject.org/wiki/XenStore
t0mek 4y ago
> although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a database engine that supports such a layout Apache Jackrabbit Oak [1] implements a tree-format data model called JCR [2]. It's used as database engine for the Adobe Experience Manager (enterprise-level CMS). [1] https://jackrabbit.apache.org/oak/docs/ https://jackrabbit.apache.org/oak/docs/ [2] https://en.wikipedia.org/wiki/Content_repository_API_for_Java https://en.wikipedia.org/wiki/Content_repository_API_for_Jav...
tablespoon 4y ago
> I suspect if the concept of the registry was created today it would look more like a database (e.g. Sqlite), although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a database engine that supports such a layout. I think you might mean relational database. IIRC, the registry is already a database, just not a relational one.
m_mueller 4y ago
hence I’ve always appreciated how mac OSX has done it: filesystem, but with a standard file format (plist files). Any well behaved mac app, if it misbehaves I can just go and delete the app settings plist and it’s just like a reinstall, since everything else is in a readonly bundle.

bluetomcat 4y ago

> The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". Every application comes up with its own format. Parsing that file is application-specific. Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that has survived in time because text files are still text files.

arsome 4y ago
To be fair, Microsoft doesn't rely on the registry for complex configurations either, even IIS uses .config files.
- justsomehnguy 4y ago
  > even IIS uses .config files. Except that is for serving from a single file share ir a replicated site across a farm of IISes. This has nothing with 'complex configurations'
- layer8 4y ago
  You can’t look at HKEY_CLASSES_ROOT and claim with a straight face it’s not complex, and it’s a central piece to how a lot of things work in Windows.
  - JonathonW 4y ago
    HKCR has a lot of entries, but the data underneath those entries isn't particularly complex. Its only really big misstep (apart from the fundamental issues with the registry in general) is that file associations and COM registrations are all intermingled in the same namespace. But those can be and are interconnected (see how the Office file types handle their registrations, for example), so it's kind of understandable how they ended up where they did.
    - layer8 4y ago
      The semantics of those entries and their possible subkeys is exceedingly complex. It started out reasonably simple, but features upon features were added with each Windows release, in addition to the application-specific behaviors.
jabbany 4y ago
Modern Linux DEs have an arguably worse version by not only having traditional `/etc` for some types of configurations but _also_ having a "registry" that's really similar to the Windows one for GUI apps... (re: gconf for Gnome)
- xattt 4y ago
  Is Gconf any different from OSX defaults?
- marcosdumay 4y ago
  "Most" here means the one DE that had a Windows fan rewrite its entire config engine with the only goal of being like Windows. An action that created quite a lot of problems soon after the change.
qsort 4y ago
Is there any "way" at all that doesn't suck though? Not having "a way" in this sense is more like a feature, a single source of truth works well if it really is treated as such by all actors. Configurations under unix are a mixture of stdin, config files, env variables and bespoke solutions. Under Windows, you have all of the above and on top of that the registry. Any attempt at a solution in this regard risks being a rerun of the notorious xkcd: 14 ways to specify configurations -> this should satisfy everyone -> 15 ways to specify configurations.
- bluetomcat 4y ago
  On a more philosophical level, the Unix convention is the "liberal" one, giving application writers more freedoms. Liberty enables more flexible applications and more chaos at the same time. A highly structured approach might be beneficial in the short run, but it might prove to be burdening beyond its due date.
  - tfigment 4y ago
    Its partly about where burden is placed. Making it easy for developers sometimes makes it hard on users and admins. And some times it becomes security issue because of varied approaches. Not sure there is right answer especially in open source where its hard to get devs.
  - trevorishere 4y ago
    Application writers are free to use which ever format they choose on Windows, as well. The Registry is just yet another option -- Microsoft does not force developers to use it. I don't see the Unix convention as the more "liberal" one, here. It typically has _one less_ option.
    - nomel 4y ago
      > The Registry is just yet another option It's not just "another option". It's a system standard option that exists, and can be easily accessed programmatically. There's no equivalent in Unix, since there is no standard, and whatever is available will depend on the distribution. "Here's a built in option, but do whatever" is very different than "do whatever!".
stockerta 4y ago
I hate this fanatical love of the UNIX way. I really hate that as of today Windows is the only non UNIX OS. I trully believe that this fact set us back. No more exciting new OSes only boring unix.
- daxvena 4y ago
  I get where you're coming from, but I think the biggest pro for the "UNIX way" is that text on a filesystem extremely accessible. You don't need a specialized tool to read & modify configuration, you just need a text editor. And while there's no standard for how the data is structured, it's usually pretty easy to figure it out from context. I think it's also really easy to underestimate all the tooling built around text. As soon as you try out some other way, you loose out on version control, diffing, grepping, and a whole bunch of other general tools built for text. I think the only way to get around this is to build generalized tools for working with binary data as a data structure. The problem with this approach is that now you need to maintain a database that describes every possible binary format, where text editors only really have to concern themselves with ASCII & unicode to be useful for most cases.
  - guhidalg 4y ago
    Windows and macOS dominate because 99.9% of users do not care about the difference between registries, file systems, text or binary tools, UNIX-like, POSIX, etc… none of these things matter to them! They just want to use a computer and get on with their life. If you lament this as a programmer, build applications that only work on your OS of choice, make them so good or take a dependency on a feature not available with macOS or Windows so that it can’t be ported, and then you can show the world the light of the UNIX mentality or whatever.
    - mhink 4y ago
      > Windows and macOS dominate because 99.9% of users do not care about the difference between registries, file systems, text or binary tools, UNIX-like, POSIX, etc… none of these things matter to them! They just want to use a computer and get on with their life. The flip side of this argument is that the experience of using computers for that 99.9% of users sucks. As software engineers, it's almost our responsibility to argue in favor of better platforms, because every day not spent fighting the platform is a day we could be building better experiences for our users. (Not to mention, every day the platform doesn't inadvertently mess up the user experience is a day of smaller support costs.)
lelanthran 4y ago
> Unix simply doesn't have a "way" in that regard, other than a loose convention to put text files in "/etc". So? The registry doesn't have much of a way either - the actual fields are simply a loose convention. > Every application comes up with its own format. Same with Windows applications - one application might store an IP address as a dotted-octet string, another might store it as a single 32 bit integer. > Parsing that file is application-specific. Same for Windows applications; the subtree for any application is very specific to that application and almost always differs from the subtree for other applications. > Updating a value in a text file means re-writing the whole file again. Not a problem, when it means that breaking a value in a text file breaks only that one application. Break the registry almost always breaks something else, if not the entire system. I'm not saying files in /etc aren't without their problems, I'm saying that all /etc problems are already present in the registry, but the registry adds a few more of its own.
- jbverschoor 4y ago
  I can’t and shouldn’t be able to write to /etc as an ordinary or guest user. Er-readying values isn’t done usually with apps. You can get corrupted files if two instances fight for the same file. If that’s your thing, please use mongo. Also, please provide support to all the users. Lastly, if you messed up certain configuration or data files, your system won’t boot either on ANY system. Sounds like you’re just one of many anti-windows people, exactly what was pointed out about people bashing the registry.
  - lelanthran 4y ago
    > I can’t and shouldn’t be able to write to /etc as an ordinary or guest user I don't believe you can. What distribution is this?
  - jbverschoor 4y ago
    Point about /etc is that it’s just one part of “configuration”. There’s no /etc for users. That’s why we get all these dot.dirs. At least some apps use ~/.config/
indymike 4y ago
> Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that has survived in time because text files are still text files. It always seems like registries are trying to solve three different problems: configuration, status and process shared state. Registries seem to work poorly compared to text files for configuration, and work somewhat well for some level of shared state. I think to compare functionality with Linux, you would have to compare /etc, .configs and the /proc filesystem. As for tecnically inferior, the *ix approach seems to have made the right tradeoffs, via the hand of Darwin, rather than some brilliant engineering insight. The article did a good job of explaining what's wrong with Windows' implementation of the registry. What is right with the *ix approach is that configuration files are usually read on startup, and only written to when configuration is changed (which should be infrequent). This works really well for server software, command line utilities, and an awful lot of GUI software. For some GUI software, particularly where you have really complex feature sets, we need to save state of widgets (i.e. saving the default zoom level) and text files may be problematic for this (i.e two instances of the app running), and this is where the registry really shines.
- mikepurvis 4y ago
  The biggest issue with etc is that it's owned by root and therefore read only from the application's point of view. So, a great fit for sysadmin-managed configuration, not so great for applications that are GUI-configurable. You end up with a tiered approach of defaults in lib, and cascaded overrides in etc and var.
  - ElectricalUnion 4y ago
    Most Linux GUI apps either litter your home folder with dotfiles, dotfolders (both disgusting) or they follow XDG Base Directory specifications and place configurations in ${XDG_CONFIG_HOME:-${HOME}/.config}
    - dklodh 4y ago
      Most don't even know of XDG. The reason is, there's no central documentation or route for the userland. By Linux, we understand, the kernel and to the kernel developers, that is true. So let alone the anarchy of the userland be handled by distributions and users.
flohofwoe 4y ago
I would actually be better if most of the data that applications store in the registry would instead live in simple text files in the AppData directory (which shouldn't be hidden by default). The registry should be restricted to Windows configuration data (like file types and their associated programs), and information that needs to be shared between installed applications.
- WorldMaker 4y ago
  That's been the recommendation since Windows 95. It's easy to suggest and hard to enforce.
marcodiego 4y ago
> Unix simply doesn't have a "way" in that regard Yes. Nothing standardized in this area in UNIX/linux-land. We do have FHS, some xdg specifications and the series of configurations options that were born with dconf which resemble windows registry a bit.
silverlyra 4y ago
OpenWRT worked around this by creating UCI, its own configuration system that it uses to generate all package-specific configuration files: https://openwrt.org/docs/guide-user/base-system/uci https://openwrt.org/docs/guide-user/base-system/uci Configuration for all supported packages is stored in files under /etc/config in UCI's own text format, and OpenWRT's init scripts generate service-specific config files based on the UCI settings when the service is (re)started. For example, to configure Samba, users don't edit smb.conf directly, they set UCI settings like samba.workgroup, sambashare.path, etc. There's a `uci` command-line utility to read and modify settings, and UCI forms the basis for the OpenWRT web interface. debconf does something similar for Debian packages, though I haven't seen any packages that use debconf to completely supplant vendor configuration formats the way UCI does. https://en.wikipedia.org/wiki/Debian_configuration_system https://en.wikipedia.org/wiki/Debian_configuration_system
MaxBarraclough 4y ago
> a loose convention to put text files in "/etc". For user-specific configuration there's also ~, as with ~/.vimrc and ~/.bashrc. Windows has something similar in C:\Users\theuser\AppData. edit And ~/.config/, as others have mentioned.

adrian_b 4y ago

The problem of removing applications together with their configurations is trivially solved in the various Linux-based systems where any software package is installed only inside a private directory. Any files that would be expected to be in shared directories like /usr/bin, /usr/lib or /etc, are replaced by symbolic links. Except for symbolic links, the installation of a package must not change anything outside its private directory. In my opinion this is the only sane way of managing software packages, because otherwise, also on Linux, but especially on Windows, I have wasted far too much time during the years with debugging various problems caused by the installation/uninstallation programs.

revolvingocelot 4y ago
>the various Linux-based systems where any software package is installed only inside a private directory Which are these? I assume Qubes OS sidesteps the problem entirely... NixOS?
- swinglock 4y ago
  NixOS, mostly, but not for application data (/var usually), which is closer to the registry.
sumtechguy 4y ago
You can do similar on windows. However, the registry was turned into trying to solve a slightly different issue of roaming users, and centrally managed settings, split by machine and user, and using what became active directory. They started off with OLE and its central store of holding name value pairs in a tree. Basically making the registry do at least 4 different things. Only one of them it does 'ok' (COM/OLE lookups). In practice it became a huge mess because thousands of applications now keep their settings in there and poor cleanup practices like you see. When like 99% of the use cases out there would be perfectly well suited to just using the forever deprecated win32 INI API to manage settings and MS just saying 'put your config files in these places for different effects'. Instead they said 'put it all in the registry'. Looking back at it, it is now 100% clear it was a bad design decision.

Someone 4y ago

> and there's no format agnostic API to access that information (you can open it, but can you understand it?). One of the critiques in this article is that, because you have to know/guess/assume what encoding is used for various strings, there isn’t one for the registry, either. If so, both approaches suffer from that (but Unix a bit more because it tends to store multiple items under a file system ‘key’, while Windows programs rarely store multiple items under a single registry key) I do wonder what RegEdit.exe does here. Does it infer encoding, have a long list of key-to-encoding mappings, or a combination of the two?

rwmj 4y ago
I do wonder what RegEdit.exe does here. Does it infer encoding, have a long list of key-to-encoding mappings, or a combination of the two? I did a bit of experimentation on this too and we think it has a heuristic to guess encodings of strings. (Which to be fair isn't a terrible idea - it's very easy and almost entirely reliable to determine if a string is ASCII/UTF-8 or UTF-16LE which are the major encodings found.)
- magicalhippo 4y ago
  Based on the documentation[1], it seems clear that strings are stored in Unicode (which should be UTF-16LE). If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, and the ANSI version of this function is used (either by explicitly calling RegGetValueA or by not defining UNICODE before including the Windows.h file), this function converts the stored Unicode string to an ANSI string before copying it to the buffer pointed to by pvData. [1]: https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-reggetvaluea#remarks https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf...
  - rwmj 4y ago
    The first thing to know about Microsoft documentation is it's almost always wrong.
    - 4y ago

pram 4y ago

AIX has a registry-like database for configuration called ODM that is like you’re describing.

samanator 4y ago

Maybe there isn't a database engine that explicitly supports file system data structures, but you could implement a filesystem in the application layer using SQLite as a storage mechanism. Here's an example of someone doing that very thing. https://github.com/guardianproject/libsqlfs https://github.com/guardianproject/libsqlfs

tauroid 4y ago
For those looking for a more up to date alternative, with a non-hardcoded DB file path, try https://github.com/greenbender/sqlfs https://github.com/greenbender/sqlfs (not affiliated, just had a look in this area a few weeks ago)

dr-detroit 4y ago

TedDoesntTalk 4y ago

Heierarcical databases support the registry format. But they are popular in the 70s?

silvestrov 4y ago

If I was to reimplement it, I would not let any app read the DB directly. Instead I would make an HTTP like interface where you talk to a service that provides the get/set functionality and which always use a text format like an extended JSON with native support for date, int32, etc. This also enabled much easier and better backwards compability as you can specify app-version in the requests, so a version 5 server can respond in version 4 format. With a service it doesn't matter if things are stored as a single sqlite DB or as multiple files.

gizmo 4y ago
You can do everything you describe with a regular function call. Introducing an unnecessary service for something as trivial as config management is even worse than the broken Registry status quo.
- imtringued 4y ago
  In theory all we need is a libconfig with a standardized interface and distro specific implementations. There would be two use cases, storing hierarchical/tree like data aka JSON, YAML, etc and arbitrary graph like data with complex references. The same could be done with the shell. libcli would be called to parse the command line arguments and your program will have an entry point that receives the parsed data. libcli could also be used to produce structured program outputs which then can be fed into applications, possibly skipping the serialisation deserialization steps. Since libcli will have a standard interface each distro can choose their own CLI format or whether they output their data as JSON or CBOR. In both cases the benefit is that the choice of the data storage mechanism has been decoupled from the application.
  - rwmj 4y ago
    Augeas does this already: https://github.com/hercules-team/augeas https://github.com/hercules-team/augeas
kreco 4y ago
Is this sarcastic? I mean, the versioning part sounds good, but JSON like request? I do believe people don't know what inefficient/efficient a system can be depending on the data format they are using.

kalleboo 4y ago

I'm a big fan of the macOS method where there's an OS API to manipulate the user defaults (as its called) but they are actually just stored as files in a standardized format (usually XML). You get the pros of the standardization and the pros of user manipulation (like easily deleting the corrupted settings of some app by removing one or two files)

LexGray 4y ago
At least that used to be the macOS method. Once Apple moved most of their apps to the cloud there are constantly open databases pushing settings updates from device to device. Things often start breaking these days if you try to fix things through direct file manipulation. With luck you might be able to find the correct terminal commands to disable services and fingers crossed they don't automatically restart themselves before you are done editing.
pxc 4y ago
Plasma/KDE has this with the kreadconfig5 and kwriteconfig5 commands, and it uses a simple INI-like format: https://userbase.kde.org/KDE_System_Administration/Configuration_Files https://userbase.kde.org/KDE_System_Administration/Configura... GNOME has the gsettings command for this, which is the equivalent of the `defaults` command in macOS. Many guides still refer users to the `dconf` command, though, which is technically a lower-level tool but basically does the same thing for 99.999% of GNOME installations. (Users/distro-makers can actually choose the storage format on GNOME's case.)

pjmlp 4y ago

What UNIX way? The religious text files scattered everywhere on the FOSS clones? The adoption of registry ideas by GNOME on gconf? The configuration databases used by HP-UX and Aix? The plists used by NeXTSTEP and macOS? The settings per app used on Android (technically UNIX based at its Linux kernel)

jollybean 4y ago
Exactly this. Unix is a bit of a mess, at least that's understandable because it's 'open'. MS registry is a bit nutty, it should be refactored in some simple, clean way, which is apparently extremely difficult to do for big companies, especially those that consider 'backwards compatibility' to be 'everything'.
- pjmlp 4y ago
  You missed the "closed" UNIXes on my comment.
- dmitriid 4y ago
  > especially those that consider 'backwards compatibility' to be 'everything'. Thank god there are companies that still think about backwards compatibility and are not intent in breaking everything because there's a shiny new thing ... ahem ... "refactoring in some simple clean way"
  - jollybean 4y ago
    Making things clear is not some kind of 'shiny new thing' that the kids are dancing to - it's rational. 'Backwards Focus Absolutism' means we live in a world of stupid cobwebs and terrible design. The Windows Registry is a hack, it was originally designed to do something mundane and simple. It just grew, like a virus.
    - dmitriid 4y ago
      > 'Backwards Focus Absolutism' means we live in a world of stupid cobwebs and terrible design It also means that until ~Windows 7/10 you could run even win3.1-era apps. And you didn't run into situations like "any 32-bit apps no longer work" or "any apps not updated in more than a year will be removed" as we've seen with Apple.

Blikkentrekker 4y ago

> The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. The problem is that everyone invented their own configuration format to store configuration data in /etc and there's no format agnostic API to access that information (you can open it, but can you understand it?). It's an interesting point and it would really be nice if there were some kind of standard, especially a standardized C library within the standard C library for configuration files, but in practice almost all of them are also easily understood `key=value` pairs that only differ by how they denote this. Still, it would be very nice to be able to inspect and modify them by standardized tools but in practice almost any configuration file opened is obvious.

chasil 4y ago

"The format is... endian-specific." Wasn't there a SPARC port of Windows? Did it run on any other big-endian machines? Were the MIPS and POWER ports little-endian? In any case, I can see why Microsoft paid SQLite for a custom set of features.

rwmj 4y ago
It's a very good question! There was also an Alpha port (both-endian and 64 bit). I've never seen a SPARC, POWER, MIPS or Alpha Windows registry so I don't know if hivex could decode them.
- the_why_of_y 4y ago
  Larry Osterman said in 2005: A decision was made VERY long ago that Windows would not be ported to a big-endian processor. https://web.archive.org/web/20190108142751/https://blogs.msdn.microsoft.com/larryosterman/2005/06/07/the-endian-of-windows/ https://web.archive.org/web/20190108142751/https://blogs.msd...

marcosdumay 4y ago

Doing that in a database is easy. You just write your keys on the "/root/path/subpath" format, and search the strings starting with some text. Most database engines have this kind of search heavily optimized. (And the ones that don't cost hundreds of thousands per core, so who cares?) The one thing you lose by using a real database is that filesystems are only locally coherent, while databases try very hard to be globally coherent. If it has heavy access, the database way will lose performance much faster.

gregmac 4y ago
Agreed, and displaying this like a tree is then a UI concern. I think you'd get slightly more performance if you were to store "Folder" and "Key" separately -- either three fields or using a parent-child table. You'd be able to index "Folder", and it would make building the tree structure itself easier and more efficient, and looking up all the values in a specific tree simpler.
cma 4y ago
You could do the paths in reverse (root last), to speed up any string comparisons, since prefix almost always matches and is maybe more wasted work the other way.

throw0101a 4y ago

> I suspect if the concept of the registry was created today it would look more like a database (e.g. Sqlite), although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a database engine that supports such a layout. (Open)LDAP uses a hierarchical structure and saves its data in a database: * https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Databa... * https://www.openldap.org/software/man.cgi?query=slapd-mdb https://www.openldap.org/software/man.cgi?query=slapd-mdb

AtNightWeCode 4y ago

There is nothing wrong with a kv hierarchy for config. Used in more modern tools as well like Consul. The problem here is the poor implementation and naive security considerations. Today, there is no broadly used file system that can replace any of this. The difference in performance is just too big.

NonNefarious 4y ago

key/value pairs

debevv 4y ago

The concept of a system-wide hierarchical key-value store is actually very useful is some environments. I had to develop one some time ago [1] for an embedded system, since is super useful to have a single point of truth/configuration/state, if every application agrees on using it (which is the case in such systems were every application is known in advance and developed in house) [1] https://github.com/debevv/camellia https://github.com/debevv/camellia

rwmj 4y ago
Xen (the hypervisor) had a thing called XenStore which was a system-wide key-value store with triggers: https://wiki.xenproject.org/wiki/XenStore https://wiki.xenproject.org/wiki/XenStore

t0mek 4y ago

> although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a database engine that supports such a layout Apache Jackrabbit Oak [1] implements a tree-format data model called JCR [2]. It's used as database engine for the Adobe Experience Manager (enterprise-level CMS). [1] https://jackrabbit.apache.org/oak/docs/ https://jackrabbit.apache.org/oak/docs/ [2] https://en.wikipedia.org/wiki/Content_repository_API_for_Java https://en.wikipedia.org/wiki/Content_repository_API_for_Jav...

tablespoon 4y ago

m_mueller 4y ago

hence I’ve always appreciated how mac OSX has done it: filesystem, but with a standard file format (plist files). Any well behaved mac app, if it misbehaves I can just go and delete the app settings plist and it’s just like a reinstall, since everything else is in a readonly bundle.