Visual C + + DLLs

A dynamic-link library (DLL) is an executable file that acts as a library of shared functions. dynamic linking provides a way for a process to invoke a function that is not part of its executable code. The executable code of the function is in a DLL that contains one or more functions that have been compiled, linked, and stored separately from the processes that use them. DLLs also help to share data and resources. multiple applications can access the contents of a single copy of a DLL in memory at the same time.

Dynamic linking differs from static linking in that dynamic linking allows executable modules (. dll files or. exe files) to contain only the information required to locate the executable code of the DLL function at run time. in a static link, the linker gets all the referenced functions from the static link library and places the library with the code in the executable file.

There are several advantages to using dynamic links instead of static links. DLL saves memory, reduces switching operations, saves disk space, is easier to upgrade, provides after-sales support, provides mechanisms to extend the MFC library classes, supports multi-language programs, and makes the creation of international versions easy.

The following topics provide more information about programming DLLs.

The content of this section

Walkthrough: Creating and Using a dynamic-link library (c + +)

Describes how to use Visual Studio to create and use DLLs.

How to: Create a class Library

Using project templates, how to create class libraries.

The difference between an application and a DLL

Describes the basic differences between an application and a DLL.

Advantages of using DLLs

Describes the advantages of dynamic linking.

DLL type

Provides information DLLs about the different types that can be generated.

DLL FAQ

Provides answers to frequently asked questions about DLLs.

To link an executable file to a DLL

Describes explicit linking and implicit linking to DLLs.

The executable file is linked to (or loaded) the DLL in one of the following two ways:

• • • header file (. h file) that contains the declaration of the exported function and/or C + + class. __declspec (dllimport), for more information, see dllexport, DllImport.

    • import library to link to (. LIB files). (the linker creates an import library when a DLL is generated.) )

    • actual DLL (. dll file).

    The operating system must be able to locate the DLL file when it loads the calling executable.

• Explicit linking

  • 　　

    Under explicit linking, an application must make a function call to explicitly load the DLL at run time. to explicitly link to a DLL, an application must:

    • Call LoadLibrary (or similar function) to load the DLL and get the module handle.

    • Call GetProcAddress to get a pointer to the function for each exported function that the application is calling. because the application is a function of invoking a DLL through pointers, the compiler does not generate external references, so you do not need to link to the import library.

    • Call FreeLibrary when you are finished using the DLL .

    • typedef UINT (callback*LPFNDLLFUNC1) (Dword,uint);               HINSTANCE hDLL; //Handle to DLLLPFNDLLFUNC1 lpfnDllFunc1;//Function PointerDWORD dwParam1; UINT uParam2, Ureturnval;hdll= LoadLibrary ("MyDLL");if(hDLL! =NULL) {LPFNDLLFUNC1=(LPFNDLLFUNC1) GetProcAddress (hDLL,"DLLFunc1"); if(!lpfnDllFunc1) {      //Handle the errorFreeLibrary (hDLL); returnSome_error_code; }   Else   {      //Call the functionUreturnval =lpfnDllFunc1 (dwParam1, uParam2); }}

      View Code

Implicit chaining is sometimes referred to as static loading or dynamic linking at load time. explicit linking is sometimes referred to as dynamic loading or runtime dynamic linking.

Under implicit chaining, the executable file that uses the DLL is linked to the import library (. lib file) provided by the creator of the DLL. The operating system loads the DLL when the executable file is loaded with the DLL. The client executable calls the DLL's exported function as if the functions were contained within the executable file.

Under an explicit link, an executable file that uses a DLL must make a function call to explicitly load and unload the DLL and access the exported function of the DLL. The client executable must call the export function through a function pointer.

The executable file can use the same DLL for both methods of linking. In addition, because one executable file can be implicitly linked to a DLL, and the other can be explicitly attached to this DLL, these mechanisms are not mutually exclusive.

Determine which link method to use:

Implicit links

An implicit link occurs when the application's code calls export DLL functions. When the source code of the calling executable is compiled or assembled, the DLL function call generates an external function reference in the object code. to resolve this external reference, the application must be supplied with the DLL's creator with the import library (. LIB file) links.

The import library contains only the code that loads the DLL and the code that implements the DLL function call. when an external function is found in the import library, the linker's code for this function is notified in the DLL. to resolve external references to DLLs, the linker simply adds information to the executable to tell the system where to look for DLL code when the process starts.

When the system starts a program that contains a dynamic link reference, it uses the information in the program's executable file to locate the required DLL. If the system cannot locate the DLL, it terminates the process and displays a dialog box to report the error. Otherwise, the system maps the DLL module into the process's address space.

The operating system calls this function if any DLL has an entry point function (for initializing code and terminating code). In the arguments passed to the entry point function, there is a code specified to indicate that the DLL is being shipped to the process. If the entry point function does not return TRUE, the system terminates the process and reports an error.

Finally, the system modifies the executable code of the process to provide the starting address of the DLL function.

As with the rest of the program code, the DLL code is mapped to the address space of the process when it is started and is loaded into memory only when needed. therefore, the preload and Loadoncall code attributes that are used by. def files to control loading in earlier versions of Windows no longer have any meaning.

explicit linking

Most applications use implicit linking because this is the easiest link method to use. but sometimes explicit linking is also required. Here are some common reasons to use explicit links:

• The application does not know the name of the DLL that needs to be loaded until run time. For example, an application might need to get the name of the DLL and the exported function name from the configuration file.

• If the DLL is not found when the process starts, the operating system terminates the process using the implicit link. also in this case, processes that use an explicit link are not terminated and can attempt to recover from the error. For example, a process can notify a user of an error and let the user specify a different path to the DLL.

• If an implicitly linked process is linked to a DLL that has any DLLs that have failed DllMain functions, the process is also terminated. also in this case, processes that use an explicit link are not terminated.

• Because Windows loads all DLLs when the application loads, applications that are implicitly linked to many DLLs start up slowly. to improve startup performance, applications can be implicitly linked to DLLs that are needed immediately after loading and wait until they are explicitly linked to other DLLs when needed.

• There is no need to link an application to an import library under an explicit link. if changes in the DLL result in export ordinal changes, applications that use explicit linking do not need to relink (assuming they call GetProcAddress with a function name instead of an ordinal value ), and an application that uses an implicit link must relink to the new import library.

The following are the two drawbacks of explicit links to note:

• If the DLL has an DllMain entry point function, the operating system calls this function in the context of the thread that calls LoadLibrary. This entry point function is not called if the DLL has already been attached to the process because the LoadLibrary was previously called and the FreeLibrary function was not called accordingly. If the DLL uses the DllMain function to perform initialization for each thread of the process, an explicit link can cause problems because the thread that exists when calling LoadLibrary (or afxloadlibrary) will not initialize.

• If a DLL declares static scope data as __declspec (thread), the DLL causes a protection error when explicitly linked. when a DLL is loaded with LoadLibrary, the DLL causes a protection error whenever the code references this data. (static scope data includes both global static items as well as local static items.) Therefore, you should avoid using thread-local storage when creating DLLs, or you should tell DLL users about potential pitfalls (when users try to load dynamically).

Initializing DLLs

Discusses the DLL initialization code (such as allocating memory) that must be executed when the DLL is loaded.

Run-Library behavior

Describes how the runtime executes a DLL startup sequence.

LoadLibrary and AfxLoadLibrary

Discusses how to use LoadLibrary and AfxLoadLibrary to explicitly link to a DLL.

GetProcAddress

Discusses how to use GetProcAddress to get the address of an exported function in a DLL.

FreeLibrary and AfxFreeLibrary

Discusses how to use FreeLibrary and AfxFreeLibrary when DLL modules are no longer needed .

The search path that Windows uses to locate the DLL:

Describes the search path that the Windows operating system uses to locate DLLs on the system.

With implicit and explicit linking, Windows first searches for "known DLLs," such as Kernel32.dll and User32.dll. Windows then searches for DLLs in the following order:

1. The directory where the executable module of the current process resides.

2. The current directory.

3. Windows system directory. The GetSystemDirectory function retrieves the path to this directory.

4. Windows directory. The GetWindowsDirectory function retrieves the path to this directory.

5. The directory listed in the PATH environment variable.

Module State of a regular DLL that is dynamically linked to MFC

Describes the module state of a regular DLL that is dynamically linked to MFC.

Extension DLLs

Explains the DLLs that typically implement reusable classes that derive from existing Microsoft base Class library classes.

Creating a pure Resource DLL

Discusses pure resource DLLs that contain only resources (superscript, Bitmap, String, and dialog boxes, etc.).

Localized resources in MFC applications: satellite DLLs

Provides enhanced support for satellite DLLs that help you create applications that are localized for multiple languages.

Import and Export

Describes how to import a public symbol into an application or export a function from a DLL.

Active Technologies and DLLs

Enables the object server to be fully implemented within the DLL.

Automation in a DLL

Describes the content provided by the automation option in the MFC DLL Wizard.

MFC DLL Naming conventions

Discusses how DLLs and libraries contained in MFC follow structured naming conventions.

Calling DLL functions from a Visual Basic application

Describes how to call a DLL function from a Visual Basic application.

Visual C + + DLLs