Space Hound 4 - [ About Duplicate Files ]

 Click HERE for Free Trial Download   Click HERE for Order form

About Duplicate Files 

Find Duplicate Files  You can search for duplicates in one of six ways:  These are:

See the Tutorial on how easy it is to use our product to manage your duplicate files.

Note: Duplicate Files can also be identified using the Microsoft Word Duplicate Content Search and the Folder Synchronization Tools.

The bottom line on removing duplicate program components today is just don’t do it at all.  In most cases, these files are small when compared to large format files such as MP3s, video files, and large graphic formats so don’t waist your time when $60 buys a few dozen more gigabytes of storage. 

The initial lines of code in Space Hound were written more than a decade ago.  Since then, there have been many changes in the way PCs store data and program files.  This program was written because there were no other programs around that supported a large hard drive (by standards current then) and could identify where all of the space was being used.  The product was almost the first to provide duplicate file searching and pioneered the technique of finding duplicates based on content alone. 

As Windows evolved from a graphical interface over DOS to a complete operating system, there existed a set of common assumptions with regards the location of application files and supporting program elements.  Over time, more and more applications made use of supporting library modules that were both custom and elements of the underlying operating system.  Numerous service packs, full operating systems releases and updates by independent software vendors resulted in a complex storage problem where a typical computer had multiple versions of these files scattered all over their hard drive.  This situation was given a name many years ago called “DLL Hell”. 

A typical example of how this worked was that Program A would require the use of a particular component that we will refer to as thing.dll.  It maintained a copy of this file within its own directory and was supplied by the software vendor.  However, Program B would also use thing.dll.  In our example, thing.dll happened to be an operating system component supplied by Microsoft.  As users applied service packs, this module was updated with new features and functions.  When Program A was written, it depended upon only the feature set within the then current release of this component.  Program B, written a year later depended upon newly included functionality that was part of a later release of the Windows operating system and included in an updated thing.dll file. 

Microsoft has allowed many elements of the core operating system to be included by software vendors so typically, a user with Windows’95 installed might have numerous components that were part of Windows’98.  The reason this was ‘ok’ was because a system component such as a DLL is designed (when done correctly) to be backward compatible. In other words, programs that required only the feature set of a Window’95 version of thing.dll found everything that they needed in the Windows’98 version so older programs worked correctly despite having a newer version of the component on the system. This was also necessary else all software vendors would have been forced to develop products while using the oldest possible version of the operating system that their users might have installed.  

The main problem was due to how Windows managed the loading and memory management of these operating system components.  An application would look first into its own directory path for the needed component and this would be loaded into memory.  If another application was launched that also relied on this component, it used the one that was already in memory instead of loading a second instance of it either from the program’s own directory or from the operating system’s path. 

The end result was that needed functionality that existed in the latest release of the software didn’t exist in the module currently loaded by the operating system.  Obviously, this would cause the newer program to crash.  Conversely, if the newer program was launched first using the latest version of the software, the older program still ran fine because everything it needed in the older version was still present in the newer version. The consequence was a newer program that sometimes crashed, sometimes didn’t.  It just depended upon the user’s sequence of events as he ran the various applications on his computer. This situation was compounded and made more difficult to track down because of another problem in earlier versions of Windows that would cause a loaded module to stay in memory if the program that placed it there crashed or terminated unexpectedly. 

Most of these problems have been resolved thanks to the release of NT based operating systems such as NT4, Windows 2000 and WindowsXP and new developer techniques that allow them to specify which copy of a component that their application wants to use.  

Unfortunately, this has resulted in turning the management of these duplicated files into a black art that few people outside of the operating system developers themselves can sort out. 

Although Space Hound will allow the user to remove and replace these program components, just as virtually all of our competitors will, we suggest you use our tool instead to study these files and to gain an understanding of the files on your system and how they interact.  Use Space Hound to manage the files that you know about such as word processing documents, downloaded music files, backups, unwanted applications, etc and leave program components to the programmers. For further background, see About File Cautions.