Windows interprocess communication (bottom)

VI. Dynamic Data exchange

Dynamic Data Exchange (DDE) is an inter-process communication form that uses data exchange between applications that exist within a share. Applications can use DDE for one-time data transfer, or they can dynamically exchange data between applications by sending updated values when new data is present.
DDE, like the Clipboard, supports both standard data formats (such as text, bitmaps, and so on) and the data formats that you define. But their data transfer mechanism is different, one obvious difference is that clipboard operations are almost always used as a one-time response to user-specified actions-such as selecting the Paste command from the menu. Although DDE can also be initiated by the user, it continues to function generally without the user further intervention. DDE has three ways of exchanging data:
(1) Cold chain: Data Exchange is a one-time data transfer, the same as the Clipboard.
(2) Win Chen: When the data Exchange Server notifies the customer, then the customer must request new data.
(3) Heat chain: The server automatically sends the data to the customer when the data is exchanged.
DDE interchanges can occur between applications on a single machine or on a different computer in the network. Developers can also define custom DDE data formats for special purpose IPC between applications, which have more tightly coupled communication requirements. Most Windows-based applications support DDE.

Take a look at the official MSDN Introduction:

Dynamic Data Exchange (DDE) is a form of interprocess communication this uses shared memory to Exchange Data between appli Cations. Applications can use DDE for one-time data transfers and for ongoing exchanges and updating of data.

Dynamic Data Exchange (DDE) differs from the Clipboard data-transfer mechanism. One difference is, the Clipboard is almost all used as a one-time response to a specific action by the User-such As clicking Paste from a menu. Although DDE can also is initiated by a user, it typically continues without the user ' s further involvement.

The Dynamic Data Exchange Management Library (DDEML) provides an interface that simplifies the task of adding DDE Capabili Ty to an application. Instead of sending, posting, and processing DDE messages directly, an application uses the functions provided by the DDEML To manage DDE conversations. A DDE Conversation is the interaction between client and server applications. The DDEML also provides a means for managing the strings and data shared among DDE applications. Instead of using atoms and pointers to shared memory objects, DDE applications create and exchange string handles, which I Dentify strings, and data handles, which identify DDE objects. The DDEML provides a function (DdenameserviceThat's enables a server application to register the service names it supports. The service names is then broadcast to and applications in the system, and which use the names-connect to the server. The DDEML also ensures compatibility among DDE applications by requiring them to implement the DDE protocol in a Consisten t manner.

Existing applications using the Message-based DDE protocol is fully compatible with those so use the DDEML; That's, an application using message-based DDE can establish conversations and perform transactions with applications Usi ng the DDEML. Instead of using DDE messages in your new application, take advantage of the DDEML and the many improvements it offers.

The DDEML, you must include the DDEML. H header file in your source files, link with the USER32. LIB file, and ensure that the DDEML. DLL file resides in the system ' s path.

Whenever a DDEML function fails, an application can call the ddegetlasterror function to determine the cause of t He failure. ddegetlasterror Returns an error value this specifies the cause of the most recent error.

This section will be discussed in detail later.

Reference: Https://msdn.microsoft.com/en-us/library/windows/desktop/ms648711%28v=vs.85%29.aspx

Https://msdn.microsoft.com/en-us/library/windows/desktop/ms648712%28v=vs.85%29.aspx

Vii. Object Linking and embedding OLE

The application uses object linking and embedding (OLE) technology to manage composite documents (documents consisting of multiple data formats), and OLE provides services that make it easier for an application to invoke other applications for data editing. For example, OLE supported word processors can nest spreadsheets, and the OLE library can automatically start the spreadsheet editor when the user wants to edit the spreadsheet. When the user exits the spreadsheet editor, the table has been updated in the original Word processor document. Here the Spreadsheet editor becomes an extension of the word processor, and if DDE is used, the user explicitly launches the spreadsheet editor.
As with DDE technology, most Windows-based Applications support OLE technology.

Applications This use OLE manage compound documents -that are, documents made up of data from a variety of diffe Rent applications. OLE provides services, the it easy-to-applications to-call on the other applications for data editing. For example, a word processor this uses OLE could embed a graph from a spreadsheet. The user could start the spreadsheet automatically from within the word processor by choosing the embedded chart for Editi Ng. OLE takes care of starting the spreadsheet and presenting the graph for editing. When the user quit the spreadsheet, the graph would is updated in the original Word processor document. The spreadsheet appears to is an extension of the word processor.

The foundation of OLE is the Component Object Model (COM). A software component that uses COM can communicate with a wide variety of all components, even those that has not yet B Een written. The components interact as objects and clients. Distributed COM extends the COM programming model so it works across a network.

Key Point: OLE supports compound documents and enables an application to include embedded or linked data so when chosen, automatic Ally starts another application for data editing. This enables the application-to is extended by any and application that uses OLE. COM objects provide access to a object ' s data through one or more sets of related functions, known as interfaces . For more information, see COM and ActiveX Object Services.

Eight, DLL

The global data in the WIN32 Dynamic Connection library (DLL) can be shared by all processes that call the DLL, which in turn opens up a new way for interprocess communication and, of course, to be aware of synchronization issues when visiting. Although you can use DLLs for inter-process data sharing, from a data security standpoint, we do not advocate this approach, and using shared memory with access control is a better approach.

Ix. Remote Procedure Call

The Remote Procedure call (RPC) provided by the Win32 API enables applications to use remote calling functions, which makes process communication with RPC on the network as simple as a function call. RPC can be used either on a single machine or in a network.
Because the RPC provided by the Win32 API obeys the OSF-DCE (Open software Foundation distributed Computing Environment) standard. So RPC applications written through the Win32 API can communicate with DEC-capable RPC applications on other operating systems. Using RPC developers, you can build high-performance, tightly coupled distributed applications.

RPC enables applications to call functions remotely. Therefore, RPC makes IPC as easy as calling a function. RPC operates between processes on a single computer or on different computers on a network.

The RPC provided by Windows are compliant with the Open software Foundation (OSF) Distributed Computing Environment (DCE). This means, that applications, use RPC is able to communicate with applications running and other operating systems T Hat support DCE. RPC automatically supports data conversion to account for different hardware architectures and for byte-ordering between D Issimilar environments.

RPC clients and servers is tightly coupled but still maintain high performance. The system makes extensive use of RPC to facilitate a client/server relationship between different parts of the operating System.

Key Point: RPC is a function-level interface, with support for automatic data conversion and for communications with other operating Systems. Using RPC, you can create high-performance, tightly coupled distributed applications. For more information, see Microsoft RPC components.

Ten, NetBios

The WIN32 API provides NetBIOS functions for handling low-level network control, primarily writing interfaces to Windows for IBM NetBIOS systems. Unless applications with special low-level network functionality are required, it is best that other applications do not use NetBIOS functions for interprocess communication.

Xi. Sockets

The Windows Sockets specification is a set of network programming interfaces under Windows defined by the socket interface that is popular in the U.c.berkeley University BSD Unix paradigm. In addition to the original library functions of the Berkeley socket, a set of functions for Windows has been extended to enable programmers to fully utilize the Windows Messaging mechanism for programming.
More and more network applications are now implemented through sockets for process communication, mainly because sockets is much better cross-platform than other IPC mechanisms, and WinSock 2.0 supports not only the TCP/IP protocol, but also other protocols such as IPX. The only drawback of sockets is that it supports the underlying communication operations, which makes simple data transfer between single-machine processes less convenient, and the WM_COPYDATA message described below will be more appropriate.

Windows Sockets is a protocol-independent interface. It takes advantage of the communication capabilities of the underlying protocols. In Windows Sockets 2, a socket handle can optionally is used as a file handle with the standard file I/O functions.

Windows Sockets is based on the Sockets first popularized by Berkeley software distribution (BSD). An application this uses Windows Sockets can communicate with other sockets implementation on other types of systems. However, not all transport the service providers support all available options.

Key Point: Windows Sockets is a protocol-independent interface capable of supporting and emerging networking. For more information, see Windows Sockets 2.

12. Wm_copydata News

Wm_copydata is a very powerful but little-known message. When an app transmits data to another app, the sender simply uses the call SendMessage function, which is the handle to the destination window, the starting address for passing the data, and the WM_COPYDATA message. The receiver simply processes the WM_COPY data message just as it does with other messages, so that data sharing is achieved between the sending and receiving parties. Wm_copydata is a very simple method, which is actually implemented by file mapping at the bottom. Its disadvantage is that the flexibility is not high, and it can only be used in a single machine environment for Windows platforms.

Data copy enables an application to send information to another application using the wm_copydata message. This method requires cooperation between the sending application and the receiving application. The receiving application must know the format of the information and being able to identify the sender. The sending application cannot modify the memory referenced by any pointers.

Key Point: Data copy can is used to quickly send information to another application using Windows messaging. For more information, see Data Copy.

Reference: Http://www.codeproject.com/Articles/115/Inter-Process-Communication-using-WM-COPYDATA

Summary: interprocess communication

Reference: Https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574%28v=vs.85%29.aspx

http://blog.csdn.net/tujiaw/article/details/6588291

Windows interprocess communication (bottom)