Windows API Reference

Documentation for the Windows Operating System API

Inter-Process Communication (IPC)

Inter-Process Communication (IPC) refers to the mechanisms provided by the Windows operating system that allow different processes to exchange data and synchronize their actions. Effective IPC is crucial for building complex, multi-component applications and for enabling seamless interaction between different software components.

Overview of IPC Mechanisms

Windows offers a rich set of IPC techniques, each suited for different scenarios:

  • Message Queues: Asynchronous communication where messages are sent to and received from a queue.
  • Pipes: Uni-directional or bi-directional data streams between processes.
  • Shared Memory: Processes can map a region of memory into their address space, allowing direct data access.
  • Sockets: Network-based communication that can also be used for IPC on the local machine.
  • Remote Procedure Calls (RPC): Enables a process to call a function in another process (potentially on a different machine) as if it were a local call.
  • COM (Component Object Model): A powerful object-oriented framework for building reusable software components that can communicate across process boundaries.
  • Windows Messaging: A fundamental mechanism for process communication using messages broadcast or sent directly between windows.

Key IPC Technologies

Pipes

Pipes are an efficient way to pass data between processes. They can be anonymous (typically for parent-child process communication) or named (allowing unrelated processes to communicate).

CreatePipe

BOOL CreatePipe(PHANDLE hReadPipe, PHANDLE hWritePipe, LPSECURITY_ATTRIBUTES lpPipeAttributes, DWORD nSize);

Creates an anonymous pipe and returns handles to the read and write ends of the pipe.

Parameters:
  • hReadPipe: A pointer to a handle that receives the read end of the pipe.
  • hWritePipe: A pointer to a handle that receives the write end of the pipe.
  • lpPipeAttributes: A pointer to a SECURITY_ATTRIBUTES structure that determines the security properties of the pipe.
  • nSize: The recommended buffer size for the pipe.
Return Value: TRUE if the function succeeds, FALSE otherwise.

CreateNamedPipe

HANDLE CreateNamedPipeA(LPCSTR lpName, DWORD dwOpenMode, DWORD dwPipeMode, DWORD nMaxInstances, DWORD nOutBufferSize, DWORD nInBufferSize, DWORD nDefaultTimeout, LPSECURITY_ATTRIBUTES lpSecurityAttributes);

Creates or opens a named pipe.

Parameters:
  • lpName: The name of the pipe.
  • dwOpenMode: The open mode.
  • dwPipeMode: The pipe mode.
  • nMaxInstances: The maximum number of instances that can be created for this pipe.
  • nOutBufferSize: The size of the output buffer.
  • nInBufferSize: The size of the input buffer.
  • nDefaultTimeout: The default timeout interval.
  • lpSecurityAttributes: Security attributes.
Return Value: A handle to the named pipe if successful, or invalid handle if failed.

Shared Memory

Shared memory allows multiple processes to access the same block of physical memory. This is one of the fastest IPC mechanisms but requires careful synchronization to avoid race conditions.

CreateFileMapping

HANDLE CreateFileMappingA(HANDLE hFile, LPSECURITY_ATTRIBUTES lpFileMappingAttributes, DWORD flProtect, DWORD dwMaximumSizeHigh, DWORD dwMaximumSizeLow, LPCSTR lpName);

Creates or opens a named file mapping object.

Parameters:
  • hFile: A handle to the file that will be used to initialize the contents of the memory-mapped file.
  • lpFileMappingAttributes: Security attributes.
  • flProtect: Protection desired for the memory-mapped files.
  • dwMaximumSizeHigh: High-order 32 bits of the maximum size of the memory-mapped file.
  • dwMaximumSizeLow: Low-order 32 bits of the maximum size.
  • lpName: Name of the mapping object.
Return Value: A handle to the created or opened file mapping object.

MapViewOfFile

LPVOID MapViewOfFile(HANDLE hFileMappingObject, DWORD dwDesiredAccess, DWORD dwFileOffsetHigh, DWORD dwFileOffsetLow, SIZE_T dwNumberOfBytesToMap);

Maps a view of a file mapping into the address space of the calling process.

Parameters:
  • hFileMappingObject: Handle to a file mapping object.
  • dwDesiredAccess: Access to the file mapping object.
  • dwFileOffsetHigh: High-order word of the offset in the file.
  • dwFileOffsetLow: Low-order word of the offset.
  • dwNumberOfBytesToMap: Number of bytes to map.
Return Value: A pointer to the mapped view of the file.
Important: When using shared memory, always use synchronization primitives like mutexes or semaphores to protect shared data from concurrent access and prevent data corruption.

Windows Messaging

Processes can send messages to each other, typically by posting or sending messages to specific windows. This is a core part of the Windows GUI model and can be leveraged for IPC.

PostMessage

BOOL PostMessageA(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam);

Places a message in the message queue of the specified thread, so that a thread can retrieve it when it calls the GetMessage or PeekMessage function.

Parameters:
  • hWnd: Handle to the destination window.
  • Msg: Message to be posted.
  • wParam: Additional message-specific information.
  • lParam: Additional message-specific information.
Return Value: TRUE if the message was placed in the message queue, FALSE otherwise.

SendMessage

LPARAM SendMessageA(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam);

Sends the specified message to a window or windows. The SendMessage function does not return until the message has been processed.

Parameters:
  • hWnd: Handle to the destination window.
  • Msg: Message to be sent.
  • wParam: Additional message-specific information.
  • lParam: Additional message-specific information.
Return Value: The return value is message-specific.
Note: When using Windows messaging for IPC, processes typically need to have associated windows or message loops.

Choosing the Right IPC Mechanism

The choice of IPC mechanism depends heavily on the application's requirements:

  • Performance: Shared memory is generally the fastest, followed by pipes and messages.
  • Complexity: Simple pipes are easier to implement than complex RPC or COM scenarios.
  • Data Volume: For large data transfers, shared memory or pipes are suitable. For small, frequent messages, Windows messaging or queues might be better.
  • Synchronous vs. Asynchronous: SendMessage is synchronous, while PostMessage and message queues are asynchronous.
  • Scope: Anonymous pipes are for related processes, while named pipes, sockets, and COM are for unrelated processes.