3 ms·

I actually miss the .ini files of early DOS / Windows days, with the defacto convention of storing them in their related program directory. They were easy to e

I actually miss the .ini files of early DOS / Windows days, with the defacto convention of storing them in their related program directory. They were easy to examine and edit with text tools, and you could do things like diffs. And when you delete the program directory, they go away as well. I used Total Uninstall on a couple Windows 7 workstations for over a decade and really paid attention to curating my registry against bloat. Almost every software out there leaves waste behind in your registry after you uninstall it. I reported some of the most egregious cases to developers/publishers over the years... a few even got fixed. But the ecosystem is a mess. I'm not sure Microsoft ever realized the importance of hammering on best practices and providing the tooling to make them effortless to follow. Even their internal teams have done some ugly stuff over the years.

pjmlp 4y ago
Same here, there was nothing wrong with them. Microsoft has been pushing for xml configuration files alongside applications, but even their own teams don't listen, so here we are.
KronisLV 4y ago
> Almost every software out there leaves waste behind in your registry after you uninstall it. I think this is just a design flaw of the implementation itself. Why couldn't every entry have a few more fields under the hood: programsDependingOnThisEntry: [PROGRAM_FOO, PROGRAM_BAR] I know that this might bloat the overall size of it, but in my experience most data structures that aren't a graph of some sort but need to be used by multiple consumers will eventually become full of orphaned data. In this example, references to actual installed programs would make sure that when you have orphaned data it can be removed automatically (or the choice given to you), much like apt might suggest that you have some packages that aren't used by any other piece of software anymore. For informative purposes, maybe also add: entryFirstAdded: 2005.05.15 14:00 entryLastChanged: 2006.11.04 17:35 entryLastRead: 2008.10.13 13:00 The timestamps could optionally assist in figuring out when the values were changed/added/actually used, so you know how important something is. If an entry hasn't been accessed in 5 years of your daily usage or something, quite possibly it isn't awfully important.
- rkagerer 4y ago
  Interestingly - as the article argues the registry is basically a crappy filesystem - the real (NTFS) filesystem already has all three of those date entries (created, modified, accessed). I agree it would be nice of all data could be seamlessly associated with the programs that have touched it. I think Android/Apple kind of do this by giving each app its own storage sandbox / directory (to some extent).

pjmlp 4y ago

Same here, there was nothing wrong with them. Microsoft has been pushing for xml configuration files alongside applications, but even their own teams don't listen, so here we are.

KronisLV 4y ago

> Almost every software out there leaves waste behind in your registry after you uninstall it. I think this is just a design flaw of the implementation itself. Why couldn't every entry have a few more fields under the hood: programsDependingOnThisEntry: [PROGRAM_FOO, PROGRAM_BAR] I know that this might bloat the overall size of it, but in my experience most data structures that aren't a graph of some sort but need to be used by multiple consumers will eventually become full of orphaned data. In this example, references to actual installed programs would make sure that when you have orphaned data it can be removed automatically (or the choice given to you), much like apt might suggest that you have some packages that aren't used by any other piece of software anymore. For informative purposes, maybe also add: entryFirstAdded: 2005.05.15 14:00 entryLastChanged: 2006.11.04 17:35 entryLastRead: 2008.10.13 13:00 The timestamps could optionally assist in figuring out when the values were changed/added/actually used, so you know how important something is. If an entry hasn't been accessed in 5 years of your daily usage or something, quite possibly it isn't awfully important.

rkagerer 4y ago
Interestingly - as the article argues the registry is basically a crappy filesystem - the real (NTFS) filesystem already has all three of those date entries (created, modified, accessed). I agree it would be nice of all data could be seamlessly associated with the programs that have touched it. I think Android/Apple kind of do this by giving each app its own storage sandbox / directory (to some extent).