PRB: Problem with Shared Data Sections in DLLs.ID: Q147136
|
Because Win32 uses path and file names to identify loaded modules, running an application that uses a DLL with a shared data section may not work correctly if the DLL will be loaded using different paths.
A memory-mapped file should be used to share data between processes.
This behavior is by design.
In Win32, module names include the path and file name, unlike 16-bit
Windows where all modules are identified with up to eight character names.
When you use a DLL with a shared data section, the path\file name
convention of identifying module names can cause shared sections to not be
shared. When the DLL is loaded a second time using a different path, the
operating system treats each instance of the DLL as a separate DLL. Because
the DLL is loaded twice as separate DLLs, no sections are shared, not even
code sections.
For example, when you map network drives E: and F: to the same share and
from each drive run an instance of an application that shares data by using
a shared data section in a DLL, the DLL is loaded separately with module
names like E:\path\filename and F:\path\filename. Each DLL will have its
own shared data section and therefore the processes will each see a
different copy of the data. In fact, shared data sections are implemented
as memory mapped files, so in this case, each instance of the DLL sets up
its own memory mapped file for a shared data section.
This problem can be diagnosed by putting a call to GetModuleFileName in the
DLL and examining the library names of each instance of the DLL. If the
names are different, shared sections will not work for the processes
calling them. The reason a file mapping is immune to the different path
names is because each process accesses a file mapping by name. File mapping
names are constant and independent of file paths.
Additional query words: 3.50 4.00
Keywords :
Version : 4.00 | 3.5 3.51
Platform : NT WINDOWS
Issue type : Last Reviewed: March 5, 1999