Sharing Data Between Different Instances of the Same Module (DLL or EXE) | CodeGuru

Sharing Data Between Different Instances of the Same Module (DLL or EXE)

Memory-mapped files are a great way to share data between processes (see Zoran’s article Client/Server Interprocess Communication Via Shared Memory).  They’re easy to create, and easy to work with ’cause you just end up with a regular-old pointer to your data.  But despite the not-too-bad syntax… CreateFileMapping(); // or OpenFileMapping() if you’re a "client" pData […]

Written By
CodeGuru Staff
CodeGuru Staff
Feb 14, 1999
2 minute read
CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

Memory-mapped files are a great way to share data between processes (see Zoran’s
article Client/Server
Interprocess Communication Via Shared Memory
).  They’re easy to create, and easy
to work with ’cause you just end up with a regular-old pointer to your data.  But
despite the not-too-bad syntax…

CreateFileMapping(); // or OpenFileMapping() if you're a "client"
pData = MapViewOfFile();
// do stuff with pData
UnmapViewOfFile();
CloseHandle();

…there’s an even EASIER way to share data between different instances of the same
application or DLL.

The Visual C++ compiler lets you name your own data segments.  You can pass an option
to the linker that tells it to share one of these custom data segments, in which case all
instances of your module (DLL or EXE) will map to the same instance of your custom data
segment.

Put this in the code module where you want the "process-global" variables:

#pragma data_seg(".SHARED")

char		pg_pszShared[256] = {0}; // variables MUST be initialized,
					 // not sure why

#pragma data_seg()

#pragma comment(linker, "/section:.SHARED,RWS")

Note that the name ".SHARED" could be whatever you want.  And you can
add almost any variables you want between the two "#pragma data_seg()" directives.  I’ve encountered two restrictions so far:
pointers that point to data that’s outside the shared segment don’t work (for hopefully
obvious reasons), and variables for classes that do their own memory-management (like
MFC’s CString) don’t work.

The "data_seg" pragma tells the compiler to put all the variables following in
the specified data segment (or rather, data section in Win32
speak).  Calling it the second time with no argument tells it to go back to using the
default data section.

The "comment" pragma passes an option to the linker that tells it to actually
share the specified data section.  You could put this in a .DEF file too. 

So anyway, as far as I’m concerned, this is MUCH cleaner than creating a memory mapped
file for every piece of data you want to share.  You don’t have to keep any handles
around and worry about closing them.  You just declare a variable in your shared
section and, voila!

Rumor has it that doing this causes the compiler to generate code that actually DOES
create a memory-mapped file behind the scenes.  Whatever.  I don’t care.  
All I know is, it’s a lot less to have to worry about.

Below is a little VCPP6 MFC program that demonstrates that this technique works.  Run a couple
instances of it, type some data in the first one, and hit "Refresh" on the
second.

Download demo application – 4 KB

Download demo project – 10 KB

Date Last Updated: February 14, 1999

CodeGuru Logo

CodeGuru covers topics related to Microsoft-related software development, mobile development, database management, and web application programming. In addition to tutorials and how-tos that teach programmers how to code in Microsoft-related languages and frameworks like C# and .Net, we also publish articles on software development tools, the latest in developer news, and advice for project managers. Cloud services such as Microsoft Azure and database options including SQL Server and MSSQL are also frequently covered.

Property of TechnologyAdvice. © 2026 TechnologyAdvice. All Rights Reserved

Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.