Windows Client Installation Problems

DLL Hell is manifest when you install your application that relies on certain system DLLs to provide specific functionality. After your system is installed and running, someone else installs his software and updates the DLLs on which your system relies. In the worst-case scenario, your application no longer functions as it did. The APIs in the replaced DLLs no longer function as your software expects them to, and your code breaks. You could take a Draconian stance that no modifications should be made to the software on a given system, but this is your customer's computer—you really cannot dictate what happens.

When you upgrade to a new version of a DLL, the old version is removed by necessity. If the new version does not work, it is not easy to go back to the old version.

Often, fragments of applications are left behind when an application or a version of an application is removed. Unused registry entries, old configuration files, sample programs, and so on might still exist.

In addition to the problem with system DLLs and DLL Hell, the old system of DLLs was insecure, and security is of great importance today. Chapter 16, “.NET Security,” is devoted completely to security issues, but this chapter explores the insecurities of the old system of DLLs that are being left behind.

A simple application is included that relies on a DLL to generate an appropriate greeting. The main portion of this file is illustrated in Listing 6.1.

Listing 6.1. Calling a Function in a DLL

#include "stdafx.h"
#include <iostream>
#include "GoodDllGoodDll.h"

int _tmain(int argc, _TCHAR* argv[])
{
    LPCTSTR message = Greeting();
    std::cout << message << std::endl;
    return 0;
}

The function in the DLL simply returns a string. The Greeting method looks like Listing 6.2.

Listing 6.2. The DLL Greeting Function

GOODDLL_API LPCTSTR Greeting(void)
{
    return _T("Hello from the good DLL.");
}

When the program runs, you get the following output:

Hello from the good DLL.

The output is satisfactory, so you can declare the application as ready to ship. The application is shipped, but at the customer's site, someone replaces the good DLL with a bad one simply by copying over the shipped file. As long as the export method signature is the same, no errors will occur. This bad DLL has a greeting that looks like Listing 6.3.

Listing 6.3. A Bad DLL Greeting Function

BADDLL_API LPCTSTR Greeting(void)
{
    return _T("I am a bad DLL. You don't want to interact with me");
}

Now when the application runs, you get this:

I am a bad DLL. You don't want to interact with me.

You can imagine this bad DLL doing something much worse than changing the message around, but you can see that it is easy to cause a program to do things that were not part of its original design. You can prevent such spoofing or tampering in numerous ways (such as file access permissions, encrypting file system, physical access restrictions, and so on), but the default allows for some large holes. The .NET Framework addresses this problem.