Software Toolbox
Home›Resources›What is DDE?
OPC Classic / Legacy Connectivity

What is DDE (Dynamic Data Exchange)?

Dynamic Data Exchange is Microsoft's original inter-process communication protocol for sharing live data between Windows applications, introduced in 1987. In industrial automation, DDE was the first mechanism that allowed HMI and SCADA software to read real-time process variable data from PLC device drivers running as separate Windows applications, without requiring custom code on each side. Understanding DDE means understanding the foundation on which the entire OPC standard was built, and recognizing why DDE's limitations made OPC necessary.

Last reviewed: 2026Reading time: ~7 minTopics: DDE, FastDDE, NetDDE, SuiteLink, Application|Topic!Item, OPC history, TOP Server DDE Client Bridge

What DDE is and how it connects to industrial automation

DDE is a Windows mechanism that lets one running application ask another running application for data, and receive updates when that data changes, using the Windows message system as the transport. It requires no special network hardware, no separate communication server, and no programming libraries: any Windows application can participate in DDE by handling the standard Windows DDE messages. This simplicity made DDE the natural choice for the first generation of Windows-based industrial HMI software when it emerged between 1989 and 1991.

The OPCConnect history of OPC describes the origin directly: the need for OPC can be traced back to Windows 3.0 in 1990, when it became possible to run multiple applications simultaneously and DDE provided a standard mechanism for those applications to exchange data at runtime. Industrial engineers immediately saw the value in having process or plant data piped into general-purpose applications like Microsoft Excel. Within a short time, the first Windows HMI products were built around DDE as their device connectivity mechanism: the PLC device driver ran as a separate Windows application called a DDE server, and the HMI software was a DDE client that requested and received data from it.

Software Toolbox's own DDE explainer, written from direct experience supporting these products, captures the era precisely: as the first Windows-based HMI software came to market between 1989 and 1991, developers chose DDE to connect HMI software to device drivers. By having the DDE server as a separate piece, it was easy for third parties to create device drivers that any DDE-capable HMI could use. This is the same interoperability problem that OPC later solved more robustly: one device driver, many HMI applications.

How DDE addressing works: Application|Topic!Item

DDE uses a three-level hierarchy to identify any piece of data in any DDE server. Every DDE conversation is established using this addressing scheme, and every data request specifies all three levels. This is directly analogous to how OPC DA later structured its address space, and how MQTT topic hierarchies work today.

RSLinx | PLC5_Data ! N7:0
Application
RSLinx
The name of the DDE server application running on Windows. This is the registered name the DDE server announces when it starts. The DDE client uses this name to establish a conversation with the correct server process among all running Windows applications.
Topic
PLC5_Data
A grouping within the DDE server, typically corresponding to a configured PLC connection or data source. Topics define the channel over which items are exchanged. A single DDE server can expose multiple topics for multiple PLCs or data sources simultaneously.
Item
N7:0
The specific data point within the topic: a PLC register address, tag name, or data file element. This is the equivalent of an OPC item ID or an OPC UA node ID. The DDE server reads this value from the physical device and returns it to the DDE client.

The separator characters matter and vary by DDE server implementation: the pipe character (|) traditionally separates Application from Topic, and the exclamation mark (!) separates Topic from Item. Some DDE servers use a backslash or other delimiter. When configuring a DDE connection in an HMI or in Excel (which supports DDE natively), you specify the full address string in this format. The DDE client broadcasts a request for the Application name, Windows finds the matching DDE server process, and a conversation is established over which the client can request Item values by Topic.

From DDE to OPC: the technology evolution

1987
DDE introduced with Windows 2.0
Microsoft releases DDE as the first standard mechanism for inter-process communication between Windows applications. Initial use case: linking Excel cells to data in other Windows applications. The protocol operates via the Windows message layer, which is synchronous and single-threaded by design.
1989-91
First Windows HMI software uses DDE for PLC connectivity
Wonderware InTouch, Fix DMACS, and other early Windows HMI products ship with DDE as their device connectivity mechanism. PLC vendors write DDE server applications (device drivers) for their hardware. Any DDE-capable HMI can connect to any DDE server using the Application|Topic!Item addressing convention. This is the first generation of vendor-independent PLC connectivity.
1992-95
FastDDE, NetDDE, and AdvanceDDE extend DDE
DDE's bandwidth and network limitations become apparent at scale. Wonderware develops FastDDE, which greatly increases the effective bandwidth of DDE by using a more efficient shared memory transport for high-speed data on the same machine, plus NetDDE for network-distributed DDE conversations. Microsoft licenses NetDDE and includes it in Windows for Workgroups through Windows XP. Rockwell Software releases AdvanceDDE as a competing performance-enhanced DDE variant. These extensions keep DDE viable but add fragmentation.
1996
OPC DA 1.0 published: the COM-based successor to DDE
The OPC Foundation publishes the first OPC Data Access specification, built on COM and DCOM rather than DDE. OPC DA addresses DDE's core limitations: it is more robust, supports network communication via DCOM without NetDDE, provides structured data (value, quality, timestamp) rather than raw strings, and defines a formal subscription model. Most PLC vendors begin releasing OPC DA servers alongside or in place of DDE servers. The transition from DDE to OPC takes most of the late 1990s and early 2000s to complete in installed plants.
2000s
DDE removed from Windows Vista onward; NetDDE discontinued
Microsoft removes NetDDE from Windows Vista and later versions, ending network-distributed DDE. Basic local DDE (on the same machine) remains in Windows only for backward compatibility. Wikipedia confirms: "DDE is currently maintained in Windows systems only for the sake of backward compatibility." At the same time, Wonderware introduces SuiteLink as the successor to FastDDE for high-performance local data exchange between Wonderware products, maintaining the same Application|Topic!Item addressing convention with a faster underlying transport.
Today
DDE survives in brownfield installations; TOP Server bridges it to OPC
Many industrial facilities have legacy DDE-based applications, custom VBA scripts in Excel that read from DDE servers, or older SCADA products that were never migrated to OPC. TOP Server's DDE Client Bridge driver allows these legacy DDE applications to connect to TOP Server as a DDE server, receiving data from any of TOP Server's 150+ device drivers via the familiar DDE interface, while TOP Server simultaneously exposes the same data to modern OPC UA clients. The DDE application does not need to be modified or replaced.

Why DDE was not sufficient for industrial connectivity

🐌
Throughput limited by the Windows message queue
DDE runs entirely through the Windows message layer, which was designed for user interface events (mouse clicks, keystrokes) rather than continuous high-frequency data streaming. On pre-Windows 95 systems, the message queue became a bottleneck for plants with more than a few hundred data points. FastDDE and AdvanceDDE partially addressed this with optimized shared memory transports, but the underlying architecture was not designed for process data volumes.
📡
No standard network support
Standard DDE was strictly local to a single machine. NetDDE added network capability but required configuration on both machines, used NetBIOS (later TCP/IP in enhanced versions), and was notoriously difficult to configure across different Windows versions. It was removed entirely from Windows Vista. OPC DA used DCOM for network connectivity, which was more reliable and better documented, though it introduced its own configuration complexity.
⚠️
Silent failures with no quality information
DDE transfers data as strings with no built-in quality field, no timestamp, and no error indication attached to each data point. If a DDE server loses its connection to a PLC, the DDE client may continue displaying the last valid value with no indication that the data is stale or invalid. OPC DA introduced the quality field (Good/Bad/Uncertain with sub-codes) and timestamp as required fields on every data value, making data validity explicit.
💬
String-only data with no type awareness
DDE carries all data as strings. A floating-point process value from a PLC register travels as the ASCII string "72.4". The DDE client must parse and convert this string to use it numerically. The DDE server has no way to communicate the data type, engineering units, or scaling of a value. OPC DA introduced typed values with engineering units and scaling information, eliminating the type conversion ambiguity that caused subtle integration bugs in DDE-based systems.
🧩
Fragmentation across DDE variants
The DDE ecosystem splintered into incompatible variants: standard Microsoft DDE, Wonderware FastDDE and NetDDE, Rockwell AdvanceDDE, and later Wonderware SuiteLink. An application built for FastDDE might not work with a standard DDE server. An application using AdvanceDDE might require specific Rockwell runtime components. OPC's COM-based standard ended this fragmentation: one OPC DA server interface, one OPC DA client interface, certified compatible regardless of vendor.
🔒
No security model
DDE has no authentication, no authorization, and no encryption. Any Windows application can establish a DDE conversation with any DDE server running on the same machine. In the isolated plant networks of the 1990s this was not a significant concern. In modern OT environments where IT/OT convergence has eliminated network isolation, a DDE server is accessible to any process on the machine without any access control.

DDE vs OPC DA: side-by-side comparison

Transport
DDE
Windows message queue. Synchronous. Constrained by message pump throughput. FastDDE adds shared memory for local high-speed variants.
OPC DA
COM for local connections (fast shared memory). DCOM for remote connections across a network. Subscription-based data delivery without polling the message queue.
Addressing
DDE
Application|Topic!Item string convention. Delimiter varies by server. No standard discovery: client must know the server name, topic, and item path in advance.
OPC DA
Browseable address space: OPC clients can enumerate OPC servers on the network, browse their item hierarchies, and discover available data points without prior knowledge.
Data types
DDE
Strings only. All values transmitted as text. Client responsible for parsing and type conversion. No engineering units or scaling communicated.
OPC DA
Typed values via COM VARIANT: integer, float, boolean, string, array, and others. Engineering units and scaling optionally included. No client-side string parsing required.
Data quality
DDE
None. No quality field. Client cannot distinguish a valid zero from a lost-connection value. Silent failures are common in poorly connected PLC links.
OPC DA
Quality field on every value (Good, Bad, Uncertain with sub-codes) plus server timestamp. Client always knows whether a value is current and valid.
Network
DDE
Local only by default. NetDDE adds network capability via NetBIOS/TCP/IP but requires complex configuration. Removed from Windows Vista onward.
OPC DA
Remote connections via DCOM. Requires DCOM configuration (port 135, dynamic ports, permissions) but is substantially more reliable than NetDDE at scale.
Status today
DDE
Basic local DDE maintained in Windows for backward compatibility only. NetDDE removed from Vista+. No new development. Supported by TOP Server DDE Client Bridge for legacy applications.
OPC DA
Still widely deployed in brownfield installations. Actively supported by TOP Server alongside OPC UA. No new features; OPC Foundation recommends OPC UA for any new connectivity work.

TOP Server DDE Client Bridge: keeping legacy DDE alive

For plants with legacy applications that communicate via DDE (custom VBA macros in Excel, older SCADA software with DDE clients, or OEM equipment with DDE-only interfaces), replacing those applications is often cost-prohibitive or operationally risky. TOP Server's DDE Client Bridge driver provides a practical alternative: it makes TOP Server appear as a DDE server to legacy DDE client applications, while TOP Server simultaneously collects data from modern PLCs and devices using its full library of 150+ device drivers and exposes that same data to modern OPC UA clients.

The DDE Client Bridge supports standard Microsoft DDE and Wonderware SuiteLink (the FastDDE successor used in current Wonderware/AVEVA products). A legacy Excel spreadsheet that reads from DDE, or a Wonderware application that reads from SuiteLink, can connect to TOP Server exactly as it would to the original device driver, while TOP Server handles the actual device communication using its modern drivers. The legacy application gets its data unchanged. Modern analytics, historian, and MES applications get the same data via OPC UA. No application modification required on either side.

SuiteLink and DDE: Wonderware's SuiteLink protocol is a high-performance replacement for FastDDE that uses the same Application|Topic!Item addressing convention but with a TCP-based transport optimized for Wonderware products. SuiteLink is not DDE itself, but it presents the same addressing interface to Wonderware clients. TOP Server's DDE Client Bridge supports both standard DDE and SuiteLink, which means it works as a drop-in data source for both classic DDE clients and current Wonderware/AVEVA InTouch and System Platform applications that use SuiteLink for their tag I/O.

Frequently asked questions

Is DDE still supported in modern versions of Windows?+−

Basic local DDE is still present in Windows 10 and Windows 11 for backward compatibility, but it is a legacy feature receiving no new development. NetDDE (network DDE) was removed from Windows Vista and is not available on any Windows version released after XP. Microsoft has not used DDE internally since Windows 95. The Real Time Automation analysis notes that Microsoft "can't really eliminate DDE without drastically changing the entire OS" because DDE is built around the fundamental Windows message system, which is why basic local DDE persists.

For industrial applications, the practical implication is that local DDE on a single machine continues to work on current Windows versions. Any application that required NetDDE for network connectivity stopped working when the site moved to Windows Vista or later. TOP Server's DDE Client Bridge maintains local DDE compatibility for applications that need it, without requiring NetDDE.

What is SuiteLink and how does it relate to DDE?+−

SuiteLink is Wonderware's (now AVEVA's) proprietary replacement for FastDDE and NetDDE. It uses the same Application|Topic!Item addressing convention that DDE applications use, but replaces the Windows message transport with a faster TCP-based transport that supports higher data throughput and network connectivity across machines on the same site. SuiteLink is not an open standard: it is specific to Wonderware/AVEVA products and requires SuiteLink components on both the server and client sides.

From an addressing perspective, a SuiteLink connection looks identical to a DDE connection: the client specifies Application|Topic!Item and receives data updates. This is why TOP Server's DDE Client Bridge supports SuiteLink alongside standard DDE: a Wonderware InTouch application using SuiteLink for its I/O connects to TOP Server using the same addressing format it would use for any SuiteLink-capable I/O server, and TOP Server provides the data from its device drivers transparently.

How do I read OPC data into Excel if my Excel uses DDE?+−

Excel has native DDE support built in and can read from any DDE server using the format =Application|Topic!Item in a cell formula. For example, =RSLinx|PLC_Connection!N7:0 reads register N7:0 from a Rockwell RSLinx DDE server. This approach works but has the limitations of all DDE: string-only data, no quality field, and local-only connectivity without NetDDE.

If you want to connect Excel to an OPC data source without replacing the DDE cell formulas, TOP Server's DDE Client Bridge lets Excel connect to TOP Server as a DDE server, which in turn collects data from any of its supported device drivers. The Excel formula stays the same: =topserver|ChannelName.DeviceName!TagName. If you want to move to a more robust Excel-OPC integration, OPC Tools includes an OPC DA Excel add-in that reads OPC items directly into Excel cells using OPC rather than DDE, including quality and timestamp information that DDE cannot provide.

Still running DDE-based applications? TOP Server bridges them to OPC UA.

The DDE Client Bridge driver lets legacy DDE and SuiteLink applications connect to TOP Server without modification. The same data, from the same device, simultaneously available to modern OPC UA clients.

Talk to an engineer