The following are some of the standard mechanisms available for
interprocess communication (IPC): NetBIOS, mailslots, windows sockets
(winsock), named pipes, anonymous pipes, semaphores, shared memory, and
shared files. Other IPC mechanisms available on Microsoft systems include
DDE, OLE, memory-mapped files, Windows messages, Windows atoms, the
registration database, and the clipboard.
The table below denotes what platforms and subsystems provide which IPC
mechanisms (this does not imply that all the mechanisms will interoperate
between different subsystems):
Interprocess Communication Mechanisms
IPC Mechanism Win2000 WinNT Win9x Win32s(1) Win16(2) MS-DOS(2) POSIX OS/2
------------- ----- ----- ------ -------- -------- -------- ----- -----
DDE YES YES YES YES YES NO NO NO
OLE 1.0 YES YES YES YES YES NO NO NO
OLE 2.0 YES YES YES YES YES NO NO NO
NetBIOS YES YES YES YES YES YES NO YES
Named pipes YES YES YES(3) YES(3) YES(3) YES(3) YES(4) YES
Windows sockets YES(5) YES(5) YES YES YES(5) NO NO(6) NO
Mailslots YES YES YES YES(3) NO NO NO YES
Semaphores YES YES YES NO NO NO YES YES
RPC YES YES YES(7) YES(8) YES YES NO NO
Mem-Mapped File YES YES YES YES NO NO NO NO
WM_COPYDATA YES YES YES YES(9) YES NO NO NO
- Win32s IS an extension to Windows 3.1 which allows Win32-based
applications to run under Windows 3.1. Win32s supports all the Win32
APIs, but only a subset provides functionality under Windows 3.1. Those
APIs that are not functional return ERROR_CALL_NOT_IMPLEMENTED.
- This is technically not a subsystem.
- Cannot be created on Win16, Windows 95 and MS-DOS workstations, but can be opened.
- The POSIX subsystem supports FIFO queues, which do not interoperate
with Microsoft's implementation of named pipes.
- Through the Windows sockets API.
- Currently BSD-style sockets are under consideration for the POSIX
- Windows 95 supports the RPC 1 protocol only. The NetBios protocol is
not supported. Namedpipe servers are not supported.
- Win32s version 1.1 provides network support through Universal Thunks.
- Under Win32s, WM_COPYDATA does not actually copy the data -- it
only translates the pointers to the data. If the receiving application
changes the buffer, then the data is changed for both applications.
- OLE objects created in a Win32 service must be in the same user
context as a logged on user that wishes to use them. Any attempt to
access these objects from a different user context will result in
failure. For example, a service that runs under the LocalSystem account
creates an object that an application running in Domain\User's context
attempts to access will fail.
Article ID: 95900 - Last Review: November 21, 2006 - Revision: 4.2
- Microsoft Win32 Application Programming Interface, when used with:
- Microsoft Windows 95
- Microsoft Windows 98 Standard Edition
- Microsoft Windows NT 4.0
- Microsoft Windows NT 3.51 Service Pack 5
- Microsoft Windows NT 4.0
- Microsoft Windows Millennium Edition
- Microsoft Windows 2000 Standard Edition
- the operating system: Microsoft Windows XP
|kbinfo kbwinsock kbnetwork kbkernbase kbipc kbfaq KB95900|