How To Share Data Between Different Mappings of a DLL

Under certain circumstances, 32-bit DLLs might have to share data with other 32-bit DLLs loaded by a different application or with different mappings of the same DLL. Because 32-bit DLLs are mapped into the calling process's address space, which is private, sharing data with other DLLs mapped into the address spaces of different applications involves creating shared data section(s) or using memory mapped files. This article discusses the former -- creating shared data sections by using the #pragma statement. Typically, system-wide hooks installed in a DLL need to share some common data among different mappings.

Each Win32-based application runs in its own private address space. If a 32- bit application installs a system-wide hook with the hook callback function in a DLL, this DLL is mapped into the address space of every application for which the hook event occurred.

Every application that the DLL gets mapped into, gets its own set of variables (data). Often there will be a scenario where hook callback functions mapped into different application or process address spaces need to share some data variables -- such as HHOOK or a Window Handle -- among all mappings of the DLL.

Because each application's address space is private, DLLs with hook callback functions mapped into one application's address spaces cannot share data (variables) with other hook callback functions mapped into a different application's address space unless a shared data SECTION exists in the DLL.

Every 32-bit DLL (or EXE) is composed of a collection of sections. By convention, each section name begins with a period. (The period is not required.) These sections can have the following attributes: READ, WRITE, SHARED, and EXECUTE.

DLLs that need to share data among different mappings can use the #pragma pre-processor command in the DLL source file to create a shared data section that contains the data to be shared.

The following sample code shows by example how to define a named-data section (.shared) in a DLL.

Sample Code

The first line directs the compiler to place all the data declared in this section into the .shared data segment. Therefore, the iSharedVar variable is stored in the .shared segment. By default, data is not shared. Note that you must initialize all data in the named section. The data_seg pragma applies only to initialized data. The third line, #pragma data_seg(), resets allocation to the default data section.

If one application makes any changes to variables in the shared data section, all mappings of this DLL will reflect the same changes, so you need to be careful when dealing with shared data in applications or DLLs.

You must also tell the linker that the variables in the section you defined are to be shared by modifying your .DEF file to include a SECTIONS section or by specifying /SECTION:.shared,RWS in your link line. Here's an example SECTIONS section: Alternatively, some compilers allow you to set the linker switch in your code so that if your file is ever copied to another project, the linker switch goes with it. To do this, include the following line in your code preferably near the #pragma data_seg(".shared") line: Be careful not to include any extraneous spaces inside the quotation marks because this may cause the linker to misinterpret the directive. In the case of a typical hook DLL, the HHOOK, HINSTDLL, and other variables can go into the shared data section.

For additional information, please see the following article in the Microsoft Knowledge Base: