Dynamic-Link Library Data
A Dynamic-Link Library (DLL) can contain global data or local data.
The default scope of DLL variables is the same as that of variables declared in the application. Global variables in a DLL source code file are global to each process using the DLL. Static variables have scope limited to the block in which they are declared. As a result, each process has its own instance of the DLL global and static variables by default.
Note that your development tools may allow you to override the default behavior. For example, the Visual C++ compiler supports #pragma section and the linker supports the /SECTION option. For more information, see the documentation included with your development tools.
Dynamic Memory Allocation
When a DLL allocates memory using any of the memory allocation functions ( GlobalAlloc(), LocalAlloc(), HeapAlloc(), and VirtualAlloc()), the memory is allocated in the virtual address space of the calling process and is accessible only to the threads of that process. A DLL can use file mapping to allocate memory that can be shared among processes.
Thread Local Storage
The thread local storage (TLS) functions enable a DLL to allocate an index for storing and retrieving a different value for each thread of a multithreaded process. For example, a spreadsheet application can create a new instance of the same thread each time the user opens a new spreadsheet. A DLL providing the functions for various spreadsheet operations can use TLS to save information about the current state of each spreadsheet (row, column, and so on). Windows Server 2003 and Windows XP: The Visual C++ compiler supports a syntax that enables you to declare thread-local variables: _declspec(thread). If you use this syntax in a DLL, you will not be able to load the DLL explicitly using LoadLibrary() or LoadLibraryEx() on versions of Windows prior to Windows Vista. If your DLL will be loaded explicitly, you must use the thread local storage functions instead of _declspec(thread).
Dynamic-Link Library Redirection
Applications can depend on a specific version of a shared DLL and start to fail if another application is installed with a newer or older version of the same DLL. There are two ways to ensure that your application uses the correct DLL: DLL redirection and side-by-side components. Developers and administrators should use DLL redirection for existing applications, because it does not require any changes to the application. If you are creating a new application or updating an application and want to isolate your application from potential problems, create a side-by-side component.
To use DLL redirection, create a redirection file for your application. The redirection file must be named as follows: App_name.local. For example, if the application name is Editor.exe, the redirection file should be named Editor.exe.local. You must install the .local file in the application directory. You must also install the DLLs in the application directory. The contents of a redirection file are ignored, but its presence causes Windows to check the application directory first whenever it loads a DLL, regardless of the path specified to LoadLibrary() or LoadLibraryEx(). If the DLL is not found in the application directory, then these functions use their usual search order. For example, if the application c:\myapp\myapp.exe calls LoadLibrary() using the following path:
c:\program files\common files\system\mydll.dll
And, if both c:\myapp\myapp.exe.local and c:\myapp\mydll.dll exist, LoadLibrary() loads c:\myapp\mydll.dll. Otherwise, LoadLibrary() loads c:\program files\common files\system\mydll.dll. Alternatively, if a directory named c:\myapp\myapp.exe.local exists and contains mydll.dll, LoadLibrary() loads c:\myapp\myapp.exe.local\mydll.dll. Known DLLs cannot be redirected. For a list of known DLLs, see the following registry key:
The system uses Windows File Protection to ensure that system DLLs such as these are not updated or deleted except by operating system updates such as service packs.
For Windows 2000, it is known DLLs can be redirected. If the application has a manifest, then any .local files are ignored. Manifests do not affect DLL redirection in Windows 2000. If you are using DLL redirection and the application does not have access to all drives and directories in the search order, LoadLibrary stops searching as soon as access is denied. (If you are not using DLL redirection, LoadLibrary skips directories that it cannot access and then continues searching.) It is good practice to install application DLLs in the same directory that contains the application, even if you are not using DLL redirection. This ensures that installing the application does not overwrite other copies of the DLL and cause other applications to fail. Also, if you follow this good practice, other applications do not overwrite your copy of the DLL and cause your application to fail.
Dynamic-Link Library Updates
It is sometimes necessary to replace a DLL with a newer version. Before replacing a DLL, perform a version check to ensure that you are replacing an older version with a newer version. It is possible to replace a DLL that is in use. The method you use to replace DLLs that are in use depends on the operating system you are using. On Windows XP and later, applications should use Isolated Applications and Side-by-side Assemblies. It is not necessary to restart the computer if you perform the following steps:
Before you make this replacement, applications will use the original DLL until it is unloaded. After you make the replacement, applications will use the new DLL. When you write a DLL, you must be careful to ensure that it is prepared for this situation, especially if the DLL maintains global state information or communicates with other services. If the DLL is not prepared for a change in global state information or communication protocols, updating the DLL will require you to restart the computer to ensure that all applications are using the same version of the DLL.