3 ms·

It's arguably a better idea than the dot-file- and /etc- mess on Linux tbh. The Windows registry is just a system-wide key/value database.

midasuni 3y ago
Easier to work with files, I can grep them, version them, diff them, edit them with any tool I want.
- flohofwoe 3y ago
  ...if you actually know where to look in the first place though...
  - iforgotpassword 3y ago
    In /etc/$toolname While in the registry it's like 5 layers deep and you need to figure out the vendor name along the way.
    - flohofwoe 3y ago
      Application specific dot-files are sometimes in the user's home directory, but sometimes also elsewhere.
    - Joker_vD 3y ago
      No, it's not there, it's in ~/.local. Or maybe ~/.cache. What is in /etc, however, is /etc/papersize. Not entirely sure who uses that, but it's there. Also, regedit supports Ctrl+F.
    - JdeBP 3y ago
      Except that it is not /etc/$toolname. Sometimes it's /etc/$subdirectory/$toolname, doing that very many-layers-deep thing that you describe. Sometimes, particularly on the BSDs, it's /usr/local/etc. Sometimes it's ~/.config/$subdirectory/$subdirectory/$thing . Or, if you are lucky, it follows the XDG rules for locating the ~/.config part. Sometimes it's ~/.$toolname . The irony is that all of the arguments about where the files are fall apart and miss the point, as the Windows registry hive file system is far more standardized than Linux-based operating systems and the BSDs are. The real discussion point is whether a structured hierarchical database of key-value pairs with typed values, accessed through an operating system API, is better as an actual database file format, with all that that implies for things like indexing and the elimination of quoting rules, text parsing, and escaping; or as text files just like it used to be with the old loads-of-.INI files system of DOS-Windows 3.
      - com2kid 3y ago
        You forgot about if the tool was installed using snap, then it is someplace different yet again!
        JdeBP 3y ago
        I didn't want to spend a whole afternoon eumerating every single possibility. Anyway, I vaguely recall that I already did in a Stack Exchange answer, which is ironic given the headlined subject, years ago. (-:
      - Modified3019 3y ago
        The galaxy brain solution is to use nixos/home manager and design your own arbitrary layout config hydra.
  - adrian_b 3y ago
    Discovering what registry key controls whatever you are interested in is not at all easier than finding a configuration file, especially because what you need may be dispersed in several keys with obfuscated names that are located in wildly different parts of the huge registry.
  - neuromanser 3y ago
    In my experience, print -l /etc/**/*foo* or grep -Ir foo /etc leads to results faster than stabbing in the dark of regedit search. Manpages usually list configuration files.
- skissane 3y ago
  > Easier to work with files, I can grep them, version them, diff them, edit them with any tool I want. Microsoft could have exposed the registry as a filesystem. R: drive or \\winreg\ or whatever. They kind of have with Powershell, but that's Powershell-specific. They could have made it part of the OS so it was available to all apps, like /proc and /sys on Linux. And then you could do all those things to them too.
  - JdeBP 3y ago
    In terms of the native API, it is viewed as a filesystem, accessed via the Object Manager like everything else. The registry is under \REGISTRY .
    - skissane 3y ago
      Not really, because although it is in the Object Manager namespace, it isn't composed of File objects, it is composed of Key objects. So the normal file APIs (e.g. NtOpenFile) don't work on it, instead you have to use NtOpenKey/etc If it were actually a filesystem, it would be composed of File objects, so you could manipulate it using the exact same API calls you use to manipulate files – which would mean that tools/utilities/apps which know how to manipulate files would just magically work on registry keys too.
- anjanb 3y ago
  The registry can store binary values. Combining binary and text values in the same files usually result in a mess for most users.
- delta_p_delta_x 3y ago
  I deeply dislike string-typed operating systems (i.e. Unix and its issue). Likewise with 'everything is a file'. OSes are a superb use-case for recursive, object-oriented, hierarchical setup and configuration, but no; Unix and friends, and the programs that run on them, insist on spewing a million-odd .ini, .cfg, .json, .yaml, .xml, .whateverml files all over the filesystem and then 'hiding' them with the leading full-stop.
JdeBP 3y ago
Actually, it's a combination of several such databases, some system-wide and some per-user. And they're held in files. So if "I don't even give a damn what format the file is in" were true, registry hive files are not a problem per se. They are just files, too. They are just not text files, as many database files on computers are not.
phinnaeus 3y ago
I think the main point of this rant is how horrible regedit is. IMO it's a fair point.
- JdeBP 3y ago
  But one that misses the point that regedit was superseded by regedt32 and even that hasn't been the only tool in the toolkit for decades. There are specialized tools like (for instance) the ODBC Data Sources utilities that edit specific parts of the registry in more structured ways; and there are generalized tools like PowerShell that actually present the Registry as if it were a filesystem. One can actually "dir" the Registry with "-recursive" and wildcards and whatnot in PowerShell. (Personally, I try to be in the habit of avoiding PowerShell's compatibility aliases, but they're there for the people who want things to appear like their old familiar MS-DOS command lines.) "I cannot edit this database file with a text editor." is an I-have-a-hammer-everything-must-be-a-nail argument. In the world of Windows and MS/PC-DOS preceding it, we've had specialized file editors for a long time. I mentioned Peter Norton in another comment. Norton Utilities and clones like PC Tools and the Graham Utilities had specialized data file editors and viewers of several kinds. PC Tools could do several of the leading MS/PC-DOS database file formats, as I recall. (I'm not getting the box out of storage and checking the manual. (-: ) The culture of MS/PC-DOS has had the idea that more than just text editors exist for many years.
bigstrat2003 3y ago
Yep, I think the registry is far better than the mess of files on Linux. On Windows the answer to "where is this configured", 95% of the time, is the registry. I'm not saying it's perfect, because it isn't. But it's better than files scattered everywhere.
Ennea 3y ago
Not just a system-wide key/value database, but one with a few optimizations on top, if memory serves me right. It's in-memory first, which I suppose makes it a tad faster and is also neat for reducing disk writes on anything that receives a lot of changes in a short amount of time. I think the concept is not too shabby. Perhaps not the best execution or tooling, but on paper, it sounds quite useful.
- fathyb 3y ago
  Another feature: .reg files!
skissane 3y ago
I think the Windows registry is a classic example of a great idea in theory, but with regrettable quality of execution. It could have been done a lot better. With a schema, self-documenting, with an integrated package database, with less insane legacy cruft. But some of that's what you get with 30 years of history, with many decisions made in another era when resources were much more limited
- Dalewyn 3y ago
  Most if not all "problems" the Registry has are due to programmers like FwarkALark: Refusing to use anything other than scattered text files of varying formats and not cleaning up after themselves. I love the Registry. It consolidates and centralizes almost everything there is to be configured in a single format, and it's even portable! Navigating it is no different than navigating a file system on a storage medium. The Registry needs more use, not less.

midasuni 3y ago

Easier to work with files, I can grep them, version them, diff them, edit them with any tool I want.

flohofwoe 3y ago
...if you actually know where to look in the first place though...
- iforgotpassword 3y ago
  In /etc/$toolname While in the registry it's like 5 layers deep and you need to figure out the vendor name along the way.
  - flohofwoe 3y ago
    Application specific dot-files are sometimes in the user's home directory, but sometimes also elsewhere.
  - Joker_vD 3y ago
    No, it's not there, it's in ~/.local. Or maybe ~/.cache. What is in /etc, however, is /etc/papersize. Not entirely sure who uses that, but it's there. Also, regedit supports Ctrl+F.
  - JdeBP 3y ago
    Except that it is not /etc/$toolname. Sometimes it's /etc/$subdirectory/$toolname, doing that very many-layers-deep thing that you describe. Sometimes, particularly on the BSDs, it's /usr/local/etc. Sometimes it's ~/.config/$subdirectory/$subdirectory/$thing . Or, if you are lucky, it follows the XDG rules for locating the ~/.config part. Sometimes it's ~/.$toolname . The irony is that all of the arguments about where the files are fall apart and miss the point, as the Windows registry hive file system is far more standardized than Linux-based operating systems and the BSDs are. The real discussion point is whether a structured hierarchical database of key-value pairs with typed values, accessed through an operating system API, is better as an actual database file format, with all that that implies for things like indexing and the elimination of quoting rules, text parsing, and escaping; or as text files just like it used to be with the old loads-of-.INI files system of DOS-Windows 3.
    - com2kid 3y ago
      You forgot about if the tool was installed using snap, then it is someplace different yet again!
      - JdeBP 3y ago
        I didn't want to spend a whole afternoon eumerating every single possibility. Anyway, I vaguely recall that I already did in a Stack Exchange answer, which is ironic given the headlined subject, years ago. (-:
    - Modified3019 3y ago
      The galaxy brain solution is to use nixos/home manager and design your own arbitrary layout config hydra.
- adrian_b 3y ago
  Discovering what registry key controls whatever you are interested in is not at all easier than finding a configuration file, especially because what you need may be dispersed in several keys with obfuscated names that are located in wildly different parts of the huge registry.
- neuromanser 3y ago
  In my experience, print -l /etc/**/*foo* or grep -Ir foo /etc leads to results faster than stabbing in the dark of regedit search. Manpages usually list configuration files.
skissane 3y ago
> Easier to work with files, I can grep them, version them, diff them, edit them with any tool I want. Microsoft could have exposed the registry as a filesystem. R: drive or \\winreg\ or whatever. They kind of have with Powershell, but that's Powershell-specific. They could have made it part of the OS so it was available to all apps, like /proc and /sys on Linux. And then you could do all those things to them too.
- JdeBP 3y ago
  In terms of the native API, it is viewed as a filesystem, accessed via the Object Manager like everything else. The registry is under \REGISTRY .
  - skissane 3y ago
    Not really, because although it is in the Object Manager namespace, it isn't composed of File objects, it is composed of Key objects. So the normal file APIs (e.g. NtOpenFile) don't work on it, instead you have to use NtOpenKey/etc If it were actually a filesystem, it would be composed of File objects, so you could manipulate it using the exact same API calls you use to manipulate files – which would mean that tools/utilities/apps which know how to manipulate files would just magically work on registry keys too.
anjanb 3y ago
The registry can store binary values. Combining binary and text values in the same files usually result in a mess for most users.
delta_p_delta_x 3y ago
I deeply dislike string-typed operating systems (i.e. Unix and its issue). Likewise with 'everything is a file'. OSes are a superb use-case for recursive, object-oriented, hierarchical setup and configuration, but no; Unix and friends, and the programs that run on them, insist on spewing a million-odd .ini, .cfg, .json, .yaml, .xml, .whateverml files all over the filesystem and then 'hiding' them with the leading full-stop.

JdeBP 3y ago

Actually, it's a combination of several such databases, some system-wide and some per-user. And they're held in files. So if "I don't even give a damn what format the file is in" were true, registry hive files are not a problem per se. They are just files, too. They are just not text files, as many database files on computers are not.

phinnaeus 3y ago

I think the main point of this rant is how horrible regedit is. IMO it's a fair point.

JdeBP 3y ago
But one that misses the point that regedit was superseded by regedt32 and even that hasn't been the only tool in the toolkit for decades. There are specialized tools like (for instance) the ODBC Data Sources utilities that edit specific parts of the registry in more structured ways; and there are generalized tools like PowerShell that actually present the Registry as if it were a filesystem. One can actually "dir" the Registry with "-recursive" and wildcards and whatnot in PowerShell. (Personally, I try to be in the habit of avoiding PowerShell's compatibility aliases, but they're there for the people who want things to appear like their old familiar MS-DOS command lines.) "I cannot edit this database file with a text editor." is an I-have-a-hammer-everything-must-be-a-nail argument. In the world of Windows and MS/PC-DOS preceding it, we've had specialized file editors for a long time. I mentioned Peter Norton in another comment. Norton Utilities and clones like PC Tools and the Graham Utilities had specialized data file editors and viewers of several kinds. PC Tools could do several of the leading MS/PC-DOS database file formats, as I recall. (I'm not getting the box out of storage and checking the manual. (-: ) The culture of MS/PC-DOS has had the idea that more than just text editors exist for many years.

bigstrat2003 3y ago

Yep, I think the registry is far better than the mess of files on Linux. On Windows the answer to "where is this configured", 95% of the time, is the registry. I'm not saying it's perfect, because it isn't. But it's better than files scattered everywhere.

Ennea 3y ago

Not just a system-wide key/value database, but one with a few optimizations on top, if memory serves me right. It's in-memory first, which I suppose makes it a tad faster and is also neat for reducing disk writes on anything that receives a lot of changes in a short amount of time. I think the concept is not too shabby. Perhaps not the best execution or tooling, but on paper, it sounds quite useful.

fathyb 3y ago
Another feature: .reg files!

skissane 3y ago

I think the Windows registry is a classic example of a great idea in theory, but with regrettable quality of execution. It could have been done a lot better. With a schema, self-documenting, with an integrated package database, with less insane legacy cruft. But some of that's what you get with 30 years of history, with many decisions made in another era when resources were much more limited

Dalewyn 3y ago
Most if not all "problems" the Registry has are due to programmers like FwarkALark: Refusing to use anything other than scattered text files of varying formats and not cleaning up after themselves. I love the Registry. It consolidates and centralizes almost everything there is to be configured in a single format, and it's even portable! Navigating it is no different than navigating a file system on a storage medium. The Registry needs more use, not less.