Cross-process sharing of a DLL's data area is another gulf between programs written in 1990 and today. Back then, all memory was implicitly visible to every program, so sharing was not an issue. In fact, programmers often went to elaborate lengths to make their DLLs store data on a per-process basis. Typically this involved some sort of code stub that mapped the current task ID to a selector assigned to the current task, and loaded the DS register with this selector. There was no explicit OS support for doing this, so various home-grown solutions sprung up. Today, the pain of per-process DLL data is gone. Win32 DLLs implicitly have their data area in per-process memory. Each DLL starts out with a fresh new copy of its data section when a new process loads the DLL. If you want to share data sections across processes, it's as easy as making a special section with the data to share, then telling the linker to give the section the SHARED attribute.
First, the app takes a time hit because of the address fix-ups and the fact that the entire DLL image must be copied to the pagefile. Second, the system takes a virtual memory hit because the pagefile must house this copy of the DLL. I have handled numerous issues in which a developer was not properly basing his huge DLLs and then wondering 1) why it takes so long for the app to load; 2) why it takes just as long for a second or third instance to load; and 3) why the app consumes so much memory.
From the July 2000 issue of MSDN Magazine.
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.