O.T removing unwanted registry entries

I'm well aware that I can do that , I was hoping for a more automated (and probably better) method. Cheers Rob

Thanks , will give it a try. Rob

Well, if you are snooping like that,and find some entry you do not like, then by all means delete the sucker, but do not complain if something goes wrong...

Does Linux have a registry? If it does, is it as bad a mess as the one in Windows?

The registry should have been an editable ascii file, or a folder full of same.

John

On 10 Oct 2005 01:24:53 -0700, snipped-for-privacy@yahoo.com wroth:

There comes a time in every computer's life when it makes sense to backup all the data files and reformat the hard drive so you can reinstall the OS and only those programs that you really use.

The only really clean registry is a fresh new one.

Jim

you can port the registry to a file.

google for RegCleaner 4.3 by Jouni Vuorio.

martin

Make that "every windows computer".

My wifes PC is on its 3rd re-install. I've never seen it needed with Linux.

There can be troubles doing this. Many PC come from the maker without a windows install disk. The disk the OS lets you make for repair purposes doesn't really work. The best plan with XP appears to be to mirror the whole hard disk and then later mirror it back.

Linux applications generally uses files in the /etc tree. Here the flaw is many different file formats, naming conventions, strange locations that configuration can *also* be read from (silently - of course) and discrepancies between what should happen with a parameter and what actually does happen.

At least one can check the /etc tree into subversion.

And one can export the Windows registry to text, edit it and yank it back in - of course it might blow up. Lots of the things are undocumented binary formats.

There are programs like RegClean, but I don't know if I'd trust them. Here's one:

Good Luck! Rich

One of the functions of the registry is to keep information about programmes that have been removed, so that timed demonstrations can't be reinstalled with their timers reset. There is necessarily encryption involved so that the user can't edit that information. Trying to do so in an 'unauthorised' way can wreck the installation and require a complete reinstallation of Windows. Third party registry cleaners probably stay clear of the encrypted areas: if they could alter them to bypass DRM, the authors might be hit hard by the miserable and loathsome DMCA.

In article , John Larkin wrote: [...]

No, there are millions of files that look a lot like old config.sys files from the MS-DOS days in the /etc directory and various subdirectories from there.

There are also a whole bunch of scripts in the "init.d" directory. These are used during boot and shut down. Detecting and setting up the RS-232 ports would be one script called perhaps "serial" and setting up the network may be in another called "network". Each is run in turn and passed a parameter of "start" during boot.

Some programs like "dosbox" or "dosemu" look in your home directory for a configuration file after they load the default one from /etc. This means that the admin can set some defaults in /etc and let you change whats safe to change in the local version.

I disagree. I think it should be several ASCII files alright. The main one should be where windows expects the main one. That file should direct windows were each of the others are. This way, the word processor would never even touch the directory that windows uses.

schreef in bericht news: snipped-for-privacy@g44g2000cwa.googlegroups.com...

Why do you want to clean it? Leave it.

- Thanks, Frank. (remove 'q' and '.invalid' when replying by email)

Linux has the /etc directory, and by gosh, it is a mess. The good thing is that every single piece of software (in my experience anyway) documents the format of its configuration file(s).

Also no (user-space) program can ever mess with the /etc settings, not even its own. Per-user settings are done in configuration files in the user's home directory.

robert

Windows attempts to use its registry for something not supported (in this manner) in *NIX systems. That is, tracking dependencies between various components like libraries (DLLs in WindowSpeak).

An uninstall is (theoretically) able to detect whan a DLL becomes 'unused' and suggest that it be deleted as well. There is nothing more frightening to a novice user than the box that pops up which suggests deleting one of these, with a hint that doing so might damage the system.

Cleanup on *NIX systems can be done by running a background job which scans each executable object for its library requirements and compares that to whats on the system. No central database needed.

Hence the necessity to shut all running programs down do do a simple update on Windows.

Tradition is to name them ".rc"

In article , Paul Hovnanian P.E. wrote: [...]

Keeping track of the "dll"s could be done in other ways and I suspect about half of them would be better than using the registry for it.

Windows has to process the whole thing at least once per system boot.

You only really care about the use count when you go to remove a program or perhaps replace a dll.

If windows programs used links to get to the shared dlls, the use counting could be done in a like manner.

IMO however, it would be better to just statically link in the code that is needed and not use the dlls at all. I've seen too many programs fail because the dlls got changed by another install.

IIRC: TI, Linear and Maxim used to ship "data CD"s that had dlls on them with the same name but that did not work with each other's program.

If you think /etc is a mess, you have a low threshold for mess. When you install programs, generally you, don't mess with each others config files. In windows land, everybody messes witht the same file so an error in one install program can trash another program.

Yes, this is a nice property of most of them. Some make hidden (".xyzzy") directory or file names for the config files.

(snip)

Interesting.

That would seem to work only for DLLs loaded at program-load time, though, not ones loaded explicitly by the program. I'm thinking of things like user-supplied extension DLLs, which you typically tell the program about on the command line or in some config file. Here's a case in which the Windows approach (wart-encrusted though it be) seems superior. Deleting a DLL that's loaded explicitly in some other program will cause massive breakage.

Cheers,

Phil Hobbs