5 ms·

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 i

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 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.

Sakos 5y ago
Also if the registry is corrupted in any way, there's no way to recover it. It's crazy that there's this single point of failure.
- pie_flavor 5y ago
  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.
  - Sakos 5y ago
    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.
    - baisq 5y ago
      I don't think I've seen or ever heard of a "corrupt registry" in my life. Are we talking about hard disk corruption or logical errors in the registry?
      - londons_explore 5y ago
        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.
      - mrguyorama 5y ago
        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.
      - Sakos 5y ago
        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.
        baisq 5y ago
        You can read the Event Viewer.
        Sakos 5y ago
        If the system isn't bootable?
        londons_explore 5y ago
        You put the disk in another windows machine and use event viewer from there
dredmorbius 5y ago
The Registry cannot be documented. Configuration files can be. Configuration files can be individually versioned and managed. Configuration files can exist in multiple instances, be swapped out or referenced for a specific invocation. I could go on. Yes, the Registry is an absolute disaster.
- Arainach 5y ago
  >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. https://support.microsoft.com/en-us/topic/how-to-add-modify-or-delete-registry-subkeys-and-values-by-using-a-reg-file-9c7f37cf-a5e9-e1cd-c4fa-2a26218a1a23 https://support.microsoft.com/en-us/topic/how-to-add-modify-... This works well and is deployed at scale in all sorts of organizations for all sorts of projects. https://support.google.com/chrome/a/answer/9131254?hl=en#zippy=%2Cconfigure-settings-on-windows-computers https://support.google.com/chrome/a/answer/9131254?hl=en#zip...
  - dredmorbius 5y ago
    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. Again: the Registry affords none of this. Let alone comments, as previously noted.
pie_flavor 5y ago
> 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.
- deleted 5y ago
  [deleted]
- formerly_proven 5y ago
  > Furthermore, the specific aspect of it you reference (that it is binary instead of textual) has almost nothing to do with the problems GP most likely means REG_BINARY littered over the place which usually means the application in question is dumping some struct into the registry.
  - londons_explore 5y ago
    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.
    - 5y ago
baisq 5y ago
>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.
flomo 5y ago
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.)
jahewson 5y ago
I always wished I could just mount the registry as a file system. Best of both worlds?
- cobalt 5y ago
  you can sort of do it in powershell you can browse it, e.g. ls HKLM:\
- jaclaz 5y ago
  JFYI there have been experiments for that (and the driver actually worked experimentally but then at the time nobody was interested): http://reboot.pro/index.php?showtopic=7681 http://reboot.pro/index.php?showtopic=7681 and multi-commander has a plugin for this (though this is more like representing the registry as a filesystem): http://multicommander.com/docs/browse-registry http://multicommander.com/docs/browse-registry As I see it the Registry format has many common points/similarities to NTFS, it is somehow a cross between a filesystem and a database or can be "seen" as either. Previous post/discussion with some more links: https://news.ycombinator.com/item?id=27940874 https://news.ycombinator.com/item?id=27940874
ogurechny 5y ago
“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.
- ygra 5y ago
  > #8-0 Is that the Coding Horror smiley?
tinus_hn 5y ago
> 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.
a-dub 5y ago
would be funny if someone wrote a comedy winfsp driver that exposed the registry as a gigantic win.ini file.
kazinator 5y ago
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.
Jaruzel 5y ago
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).
- londons_explore 5y ago
  Is cleaning up actually necessary though? I don't delete old emails in my inbox, yet life goes on and it isn't an issue. Occasionally having that old stuff is helpful.
  - eternityforest 5y ago
    It's more helpful when you can see it without reinstalling the app.
skissane 5y ago
> 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.
jiggawatts 5y ago
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...
dtheodor 5y ago
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 https://sqlite.org/appfileformat.html
- eternityforest 5y ago
  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.

Sakos 5y ago

Also if the registry is corrupted in any way, there's no way to recover it. It's crazy that there's this single point of failure.

pie_flavor 5y ago
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.
- Sakos 5y ago
  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.
  - baisq 5y ago
    I don't think I've seen or ever heard of a "corrupt registry" in my life. Are we talking about hard disk corruption or logical errors in the registry?
    - londons_explore 5y ago
      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.
    - mrguyorama 5y ago
      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.
    - Sakos 5y ago
      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.
      - baisq 5y ago
        You can read the Event Viewer.
        Sakos 5y ago
        If the system isn't bootable?
        londons_explore 5y ago
        You put the disk in another windows machine and use event viewer from there

dredmorbius 5y ago

The Registry cannot be documented. Configuration files can be. Configuration files can be individually versioned and managed. Configuration files can exist in multiple instances, be swapped out or referenced for a specific invocation. I could go on. Yes, the Registry is an absolute disaster.

Arainach 5y ago
>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. https://support.microsoft.com/en-us/topic/how-to-add-modify-or-delete-registry-subkeys-and-values-by-using-a-reg-file-9c7f37cf-a5e9-e1cd-c4fa-2a26218a1a23 https://support.microsoft.com/en-us/topic/how-to-add-modify-... This works well and is deployed at scale in all sorts of organizations for all sorts of projects. https://support.google.com/chrome/a/answer/9131254?hl=en#zippy=%2Cconfigure-settings-on-windows-computers https://support.google.com/chrome/a/answer/9131254?hl=en#zip...
- dredmorbius 5y ago
  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. Again: the Registry affords none of this. Let alone comments, as previously noted.

pie_flavor 5y ago

> 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.

deleted 5y ago
[deleted]
formerly_proven 5y ago
> Furthermore, the specific aspect of it you reference (that it is binary instead of textual) has almost nothing to do with the problems GP most likely means REG_BINARY littered over the place which usually means the application in question is dumping some struct into the registry.
- londons_explore 5y ago
  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.
  - 5y ago

baisq 5y ago

>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.

flomo 5y ago

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.)

jahewson 5y ago

I always wished I could just mount the registry as a file system. Best of both worlds?

cobalt 5y ago
you can sort of do it in powershell you can browse it, e.g. ls HKLM:\
jaclaz 5y ago
JFYI there have been experiments for that (and the driver actually worked experimentally but then at the time nobody was interested): http://reboot.pro/index.php?showtopic=7681 http://reboot.pro/index.php?showtopic=7681 and multi-commander has a plugin for this (though this is more like representing the registry as a filesystem): http://multicommander.com/docs/browse-registry http://multicommander.com/docs/browse-registry As I see it the Registry format has many common points/similarities to NTFS, it is somehow a cross between a filesystem and a database or can be "seen" as either. Previous post/discussion with some more links: https://news.ycombinator.com/item?id=27940874 https://news.ycombinator.com/item?id=27940874

ogurechny 5y ago

“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.

ygra 5y ago
> #8-0 Is that the Coding Horror smiley?

tinus_hn 5y ago

> 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.

a-dub 5y ago

would be funny if someone wrote a comedy winfsp driver that exposed the registry as a gigantic win.ini file.

kazinator 5y ago

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.

Jaruzel 5y ago

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).

londons_explore 5y ago
Is cleaning up actually necessary though? I don't delete old emails in my inbox, yet life goes on and it isn't an issue. Occasionally having that old stuff is helpful.
- eternityforest 5y ago
  It's more helpful when you can see it without reinstalling the app.

skissane 5y ago

> 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.

jiggawatts 5y ago

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...

dtheodor 5y ago

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 https://sqlite.org/appfileformat.html

eternityforest 5y ago
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.