The amount of junk that gets entered into the Windows Registry and never removed is crazy, blame Microsoft and their creation of the registry mess and the other applications that don't clean up rather than the clean up tools that try fix it and performance issues.
First off, stuff that get's entered into the registry and never removed doesn't slow the system down.
Second they created the registry as a central settings repository. At the time trying to find out where a program saved it's settings was a matter of finding the right INI file. And oftentimes you'd have INI files all over the drive, and a lot of programs decided to just save their settings in WIN.INI, and since there was a built in limit of 64K for INI files this would often corrupt WIN.INI making the system unbootable.
As for 'RAM compression' it's just unloading unused windows dlls and defragging your memory. Only helpful if you haven't got that much memory, which is cheap these days, so not really needed anymore.
No. All it does is page <everything> out of RAM to the page file. You just end up paging it back into main memory. Not very productive. All it does is slow you down and give you a higher amount of free <physical> memory, at least for the short time you stand there staring at the little system tray icon showing free RAM. the moment you switch to another application you are greeted with disk trashing as that applications <entire> address space is paged in- not just the stuff that windows would have decided, over time, to page out because it wasn't used, but the entire thing. In either case, it's not helpful regardless of how much RAM you actually have.
Advanced SystemCare does a great job at helping keep your system and registry clean.
forgetting the rest of that first paragraph (startup manager? sounds more like a pretty face on copying registry keys, sure hope SystemCare stores those startup configs in a file, otherwise it's contributing to a "dirty" registry.
Which brings me back to the specific quote- I take odds against this one- how do you define a "Clean" registry? What is the difference between a "Clean" system or registry and a "dirty" one?
Just because the registry has a lot of keys/values that are not used and/or are forgotten does not constitute a "dirty" registry. In fact, I contend that since the registry cannot actually be made "dirty" it's also impossible to define exactly what "cleaning" the registry is, and this particular opinion is backed up by the fact that even those companies/individuals that create registry cleaners don't even come close to agreeing. one might find double, or three times the number of "obsolete" entries in the registry.
I've already covered this, in a lot of posts- but aside from the fact that defining a "Dirty" is impossible to reason out, it's equally impossible to determine programmatically.
First off, many people would contend that unused sections/keys in the registry are not used. This seems sensible.
However- how does a registry cleaner decide what is, and is not used? How does it "know" what registry keys are actually being used by applications and which ones aren't?
And of course there are the ones that go completely overboard and try to determine what registry keys are "invalid" this is an equally futile endeavour. Other applications store this data. Only the other applications know what it's for.
A lot of cleaners "recognize" when a REG_SZ value is a filename.
A lot of these cleaners determine that if that file does not actually exist, then the key is invalid.
However, what if the application uses that setting to determine where to <Create> a file or folder? Did the cleaner not just screw up that application? what happens when it starts up? Who knows! It might even crash! IF registry "dirt" like that caused crashes, you would think that "cleaning" the registry would do the opposite, but it doesn't always work that way.
I contend that the only Hive that can get "dirty" is the HKEY_CLASSES_ROOT key, (which is really just an alias for HKEY_LOCAL_MACHINE\software\clsid key). why?
it's format is well defined- but! here's the kicker!
the format is <Not> documented! each version of windows introduced new values and keys within the classes key that changed or even made current "cleaning" tools redundant. The only actual cleaner would be a simple loop through all the keys. if that key has a DLL file reference that exists then it's valid. if not, delete it. This is especially the case when converting the defined progID to a CLSID does not actually reflect the CLSID of the component.
That's it. you cannot "clean" any of the other hives, merely because you cannot define what a "dirty" registry is any more then you can say wether a file on your file system is unused.
