Since the beginning of time (well, since the ealiest versions of Windows first appeared anyway...), the operating system and any applications running on it have relied upon the presence of .DLL's (Dynamic Link Libraries), these objects contain common functions and code that the O/S and/or the applications need to use from time to time. .DLL's can be unique to a particular application, or they can be shared between applications and the underlying operating system , these .dll's are known as 'Common' or 'System' .dll's, and are used to provide common programming functions used by both the o/s and its applications.
The problem stems from the fact that Microsoft, with all its releases, Service Packs and Hotfixes, may produce several versions of a particular System .DLL over a period of time, all of which may have subtle differences in functionality and behaviour, whilst ostensibly delivering the same end result as far as the user is concerned. Software Developers often utilise these system .dll's for some functionality of an application, and may require (or rely on), the behaviour or functionality of a certain version of a particular system .dll in order for their application to perform correctly. Whilst the Microsoft line might be that developers should use their latest release of a system .dll is in their code, this is not always possible due to the frequent o/s updates Microsoft typically issues as described earlier, and also they may require the functionality of a particular version of a system .dll that isnt present in the latest replease. So traditionally, to circumvent this problem, many developers have chosen to bundle the version of the system .dll they require with the setup routine for their application, thus ensuring that the target machine will run their code correctly. Fine....
The fun usually starts when you install several such applications, all demanding a different version of the .dll. This (as Im sure many of you will have experienced) can cause havoc with either one or more of the applications, or even the o/s itself (some .dll's rely on the presence and functionality of other .dll's in order to work correctly).
This malpractice of behalf of developers, has given rise to a whole arm of I..T Services - Application Intergration, or in laymans terms 'The Art of Making Several Applications Developed by Several 3rd Parties Work Together on One System', and its kept me in work for some years off and on. However, thats no excuse,and Microsoft HAD to come up with a solution to force developers to tow the line, and it actually looks like they might have achieved it in Windows 2000.........
In Windows 2000 System .dll's are known as 'Protected' .dll's. They are protected in such that only an application with a correct Digital Signature, such as the application of a Service Pack or Hotfix, is allowed to change them. If a third party attempts to overwrite a system .dll in Win2k, the system can detect, by means of a digital signature within the .dll, that the upgrade is unauthorised, and the original version is automatically restored from the 'DLL Cache' a folder containing the latest o/s approved versions of all registered system .dll's. If the correct version is not found in the cache, then installation media is requested containing the correct (authorised) version of the file.
The result of this is that it becomes impossible for wayward software developers to introduce spurious .dll's into the o/s. It forces developers to either not use system .dll's in their code, or to write their code in such a way that the version of a system .dll doesnt affect the applications functionality. Windows 2000 helps here too. It allows an application to load a 'Private' version of a system .dll, solely for use by the application that needs it, this version may be different than the version in use by the o/s. The o/s is thus isolated from the application, providing far greater stability than in previous versions of Windows.
This mechanism is known as the Windows File Protection System and is an integral part of Windows 2000.