How to implement inter-process data communication technology

1. Introduction

In Windows programs, there is often a need to exchange data between processes for data communication. The WIN32 API provides a number of functions that allow us to communicate between processes in a convenient and efficient way, through which we can control the exchange of data between different processes, just as the local process is read and write in WIN16.

A typical WIN16 two process can be exchanged for data exchange through Shared memory: (1) process A will GlobalAlloc (Gmem_share ...). API allocates a certain length of memory; (2) process a passes the handle returned by the GlobalAlloc function to process B (via a login Message), (3) process B invokes the GlobalLock function on the handle, and accesses the data using the pointer returned by the GlobalLock function. This method may fail in WIN32 because the GlobalLock function returns to the memory of process A, because the process uses a virtual address rather than an actual physical address, so this pointer is only related to a process and not to the B process.

In this paper, several implementation methods of communication between processes under WIN32 are discussed, and readers can use different methods to achieve efficient and reliable program operation.

2. Memory space management of process in WINDOWS95

WIN32 interprocess communication is closely related to Windows95 's memory management, understanding that WINDOWS95 memory management will be of great help to our programming as follows, we discuss the memory space management of processes in the following Windows95.

Under WIN16, all Windows applications share a single address, and any process can read and write to a shared single address space and memory belonging to another process, or even access data from the operating system itself, potentially damaging the data snippet code of other programs.

Under WIN32, each process has its own address space, a WIN32 process cannot access private data for another address, and two processes can be addressed with pointers with the same value, but read and write only their respective data, which reduces the interaction between processes. On the other hand, each WIN32 process has a 4GB address space, but it does not mean that it actually has 4GB of actual physical memory, but only the virtual address space provided by the operating system using the CPU's memory allocation feature. In general, the vast majority of virtual addresses do not correspond to physical memory, and the actual physical memory is provided by the operating system before they can actually be used (the process is called “ submit ”commit). In different cases, the physical memory submitted by the system is different, may be RAM, or it may be virtual memory emulated by the hard disk.

3. Communication between processes in WIN32

In Windows 95, users can have several options for achieving an equal process of data exchange:

* Use memory-mapped files

* Shared memory through shared memory DLL

* Send a WM_COPYDATA message to another process

* Call ReadProcessMemory and writeprocessmemory functions that the user can send by GlobalLock (Gmem_share,...) The handle that is fetched by the function call, the pointer returned by the GlobalLock function, and the pointer returned by the VirtualAlloc function.

--3.1, using memory-mapped files to implement communication between WIN32 processes

The mechanism of memory-mapped files in Windows95 provides a way for us to efficiently manipulate files, allowing us to preserve a section of memory in the WIN32 process and map the target file to this virtual memory. Synchronization between processes must be considered in the implementation of the program. The following steps are implemented:

First we need to create a well-known shared memory by calling the memory-mapped API function createfilemapping in the process of sending data:

　　HANDLE CreateFileMapping(
　　 HANDLE hFile, // 映射文件的句柄，
　　 //设为0xFFFFFFFF以创建一个进程间共享的对象
　　 LPSECURITY_ATTRIBUTES lpFileMappingAttributes, // 安全属性
　　 DWORD flProtect, // 保护方式
　　 DWORD dwMaximumSizeHigh, //对象的大小
　　 DWORD dwMaximumSizeLow,
　　 LPCTSTR lpName // 必须为映射文件命名
　　 );

Similar to virtual memory, the protection can be page_readonly or page_readwrite. If multiple processes have write access to the same shared memory, you must maintain synchronization between each other. The mapping file can also specify the PAGE_WRITECOPY flag to ensure that its original data is not compromised, while allowing other processes to manipulate the copy of the data as necessary.

After creating the file mapping object, use the address space that you can call the MapViewOfFile function to map to this process.

The following description creates a well-known mapping file named Mysharedmem with a length of 4096 bytes:

HANDLE hmysharedmapfile=createfilemapping ((HANDLE) 0xFFFFFFFF),

null,page_readwrite,0,0x1000,“ mysharedmem”);

and map the buffer view:

LPSTR pszmysharedmapview= (LPSTR) mapviewoffile (Hmysharedmapfile,

file_map_read| file_map_write,0,0,0);

Other processes access the shared object, need to get the object name and call the OpenFileMapping function.

HANDLE hmysharedmapfile=openfilemapping (File_map_write,

false,“ Mysharedmem ");

Once the other process gets the handle to the mapped object, you can call the MapViewOfFile function to map the object view as you would create the process. Users can use this object view for data read and write operations to achieve the purpose of data communication.

When the user process ends using shared memory, call the UnmapViewOfFile function to cancel the view in its address space:

if (! UnmapViewOfFile (Pszmysharedmap

View))

{AfxMessageBox (“could not unmap view of file);}