“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

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