There are any number of programs available that will claim to search your hard drive and remove any duplicate files. Most of these programs do a pretty good job, but it's worth having an understanding of what impact removal of system files and application components can have upon your computer.

Sanx's pocket guide to DLLs, OCXs and TLBs

DLLs, OCXs and TLBs are sections of code that exist in a different file to the main program file - the executable.

DLLs (Dynamic Link Libraries): Programmers often use DLLs when they have sections of code they wish to share between applications, but don't want to duplicate in each application. Placing this code in a DLL allows multiple applications to access it whilst keeping the overall application size down.

OCXs (OLE Component Extensions): OCXs tend to be visual components or objects. Where a programmer wants to use a certain style of button or list box, he'll use an OCX to make it. This saves him from having to write all the code to display the button manually. He just puts it there using the OCX, and all the actions come pre-packaged without him having to worry about coding what happens to the button image when the user clicks his mouse on it.

TLBs (Type Libraries): Type libraries are basically definitions of data structures - methods in which information is stored and transfered. Whilst these are usually stored in the application itself, having thm stored in a separate file allows the programmer to use the same type definitions across more than one program.

So what happens when a programmer uses one of these files and you install their program on your computer? In the vast majority of cases, the process is seamless. The setup program copies down the files, registers them properly and the application works without any thought or other configuration required. Problems can occur however, when different applications use the same components.

Whilst this is not an issue for custom-written DLLs and OCXs (i.e. ones the programmer has written themselves), there can be a problem when the programmer uses stock components. Visual Basic comes with a whole bunch of these, as does Visual C++ and a whole number of other programming languages. The problem arises because the programmer cannot automatically assume that the machine on which the software is going to be installed has all the pre-requisite components already on it. And even if it does, he cannot assume that all the components will be the right version.

Because of this, he will usually package up into his setup routine all the components the application will require. Now, this may end up containing duplicates of what is already on the target machine.

To cope with multiple versions, Windows has a built-in way of handling calls to external components. If an application makes a call to a certain DLL (let's call it sanx.dll) Windows will first look in the directory in which the application resides, and then in the \Windows\System32 directory.

Should the programmer need a specific version of a component, he can install it in the application directory. If it's going to be a common one, he can put it in the System32 folder.

The issue really starts getting fuzzy when you realise that in addition to the component actually having to be on the machine, it also needs to be registered. Registration of a component involves writing a whole bunch of GUIDs (Globally-unique identifiers) to the registry. Registration basically makes the component available to applications under a certain name and identifier without the programmer having to reference it by path and filename - quite a good thing since the programmer doesn't know in advance into what directory you've installed Windows or what directory you're going to put his program. Because of this, it's quite possible to have two or more identical components in different places on the machine, with different identifiers. Removing one will probably break the program associated with it.

Let's say sanx.dll exists on your machine in two places; your Windows\System32 directory and in the directory into which you've installed Sanx's ReallyWonderfulDoEverything application - the program that uses sanx.dll. Which version of sanx.dll will it be using? Well, that depends on where the registered version of the component is - something that can be devilishly hard to find. Even if both versions are registered, you'd need to know which of the two identifiers the program is using. Removal of the wrong copy of sanx.dll (i.e. the registered one) will end up breaking Sanx's ReallyWonderfulDoEverything. And that's a bad thing.

-- End pocket guide --

Thanks for reading this far!

So what does all of the textual garbage above mean? Basically, it means be very careful. Most disk cleaners will have some functionality that will search down any unregistered components, and look for registration entries that point to components that no longer exist.

Every good disk cleaner will also have a backup facility that allows you to save all the files deleted to an archive, along with any associated registry entries. If yours doesn't have that facility, don't use it - find another one. Remember, backups are your friend.

You might also want to consider doing a full backup, or at least saving all of your data onto remvoable media so that if you do end up breaking Windows beyond repair a format isn't going to cause you to lose anything you cannot replace. Remember to include your email storage files, ICQ contacts database, etc. in this.