This article was previously published under Q147136
This article has been archived. It is offered "as is" and will no longer be updated.
Because Win32 uses path and file names to identify loaded modules, runningan application that uses a DLL with a shared data section may not workcorrectly 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-bitWindows where all modules are identified with up to eight character names.
When you use a DLL with a shared data section, the path\file nameconvention of identifying module names can cause shared sections to not beshared. When the DLL is loaded a second time using a different path, theoperating system treats each instance of the DLL as a separate DLL. Becausethe DLL is loaded twice as separate DLLs, no sections are shared, not evencode sections.
For example, when you map network drives E: and F: to the same share andfrom each drive run an instance of an application that shares data by usinga shared data section in a DLL, the DLL is loaded separately with modulenames like E:\path\filename and F:\path\filename. Each DLL will have itsown shared data section and therefore the processes will each see adifferent copy of the data. In fact, shared data sections are implementedas memory mapped files, so in this case, each instance of the DLL sets upits own memory mapped file for a shared data section.
This problem can be diagnosed by putting a call to GetModuleFileName in theDLL and examining the library names of each instance of the DLL. If thenames are different, shared sections will not work for the processescalling them. The reason a file mapping is immune to the different pathnames is because each process accesses a file mapping by name. File mappingnames are constant and independent of file paths.