PRB: Problem with Shared Data Sections in DLLs.

• Microsoft Win32 Software Development Kit (SDK) for:

      - Windows NT versions 3.5 and 3.51
      - Windows 95 version 4.0
  

SYMPTOMS

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.

RESOLUTION

A memory-mapped file should be used to share data between processes.

STATUS

This behavior is by design.

MORE INFORMATION

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.