Monday 19 October 2009

DDE Is Still Alive & Kicking

Dynamic Data Exchange (DDE) is an ancient inter-process communication (IPC) mechanism carried over from the 16-bit Windows days. Post millennium Windows programmers are probably more used to a diet of COM, but there still seems to be life in the old dog yet. Maybe there are less people around to answer questions on DDE, or perhaps the other old timers are ignoring them in the hope they'll go away because I seem to have had more emails on the subject this year than ever.

I presume the reason the questions are still coming my way is because I have a number of freeware tools on my website aimed at working with DDE Servers that are still actively supported:-

  • DDE Query is my oldest tool and is a GUI based utility for sending requests and creating advise loops on items. It was written as the main test harness for my DDE library.
  • In contrast DDE Command is my most recent addition and is the console based counterpart to DDE Query. It also provides the ability to invoke XTYP_EXECUTE transactions.
  • In between the two is my DDE COM Client - an automation compatible inproc COM component that can be used as a DDE Client for scripting scenarios, such as VBScript.
  • The final, and second oldest utility I provide, is a Network Bridge to allow DDE Servers to be accessed remotely. It is entirely transparent to the client and server, unlike the built-in Windows NetDDE service.

These all use my own C++ DDE library which in turn is based on the DDEML C-API library that Microsoft provides. Under the covers DDE is just a message based protocol that uses Windows messages to encapsulate a connection between two applications – known as a Conversation. Data is passed by allocating it with the old GlobalAlloc() API, and the format is determined by either using a standard clipboard format, such as CF_TEXT or a custom one via RegisterClipboardFormat(). The fact that it is message based is also its biggest limitation as it means you cannot share data between machines – you can't even share data across desktops on the same machine. The only book I came across on the subject was Ole 2.0 and Dde Distilled by Al Williams, but it covers the topic pretty thoroughly.

Before working in finance the only time I had come across DDE was when writing an installer back the mid 90's. Under Windows 3.x you used DDE to communicate with Program Manager (the shell that today is known as Explorer) so that you could create a "Program Group" and the icons for your application. You can still see this legacy today if you fire up DDE Query and use the "Server | Connect…" option, where you will spot a server called PROGMAN with a single topic also called PROGMAN. If you open this conversation and request the item "Accessories" you will be shown a CSV formatted text block with the programs from the Accessories Start Menu folder.

Once I started working in finance I discovered that Excel was the traders tool of choice. Excel can pull data from a number of sources, but the legacy option for real-time data was DDE. The big providers like Reuters, Telerate & Bloomberg all provided tools to allow you to feed their financial data into a spreadsheet and the in-house software we developed followed the same architecture. Although COM was probably Microsoft's promoted technology, DDE felt far simpler to implement.

These days I don't work with that kind of real-time feed, but the questions I do get on DDE always seem to have RIC's in the examples, so I guess that it's the financial industry that is keeping this prehistoric mechanism alive.


  1. Chris - if you were desigining a C# app today that had to communicate with another C# application in real-time, would you even consider using DDE, or would something like WCF be your more likely choice?

  2. No I wouldn't consider DDE. WCF seems like the obvious choice to me. Even raw sockets seems like far too much hassle given what WCF brings to the party.

  3. Sorry for my bad english.
    This is the problem: I have an excel that receive data from my bank via dde and I want to share this data with an other pc on my home network.
    I have downloaded your dde tools DDE Network Bridge and DDE Query.
    In the excel there is this string: =DDESXT|SR!'IDEM;MINII0;20100902;000000;000000;60;DVOCHL'
    I suppose that DDESXT is the DDE server name, all between ' are parameters sapareted by ; and SR ?
    I stated Netdde server on the pricipal pc and Netdde client on the other, with Service=PC1 (the principal pc) and Server=DDESXT.
    If I use DDE Query on the principal pc and connect to dde server with Service=DDESXT and Topic=SR (or System) it's ok, but if I try on the other pc it fails.
    Where is the error ?
    If you like, you can respond to
    Thanks !

  4. The textual format of a DDE link is:-


    This is documented in the following MSDN article:-

    Usually server is also the name of the executable, but it doesn't have to be. The topic is often the document name (excel) or service (reuters) and the item is, well, the 'path' to the value. In the simple case for excel this is a single cell and for reuters it's a field in a RIC.

    I will respond about my Network DDE and DDE Query tools by email. Should there be a problem contact me directly via

  5. I have a problem with a DDE client, I put my problem and if you can you comment me some solution or because of this error. I have a desktop application written in C #, this is a DDE client using NDde.dll bookstore. So far so good. Aora'm trying to implement as an operating system service, but can not get the client to connect to the DDE server. Nose whether it will issue permits or code, but as I mentioned in the desktop application works well.

  6. @Isidro You can't do this (directly) as DDE works by sending Windows messages. The NT Service will live in a different "Session" to your desktop and so the Windows messages cannot pass between them.

    The reason I say "directly" is that you could do something similar to how my DDE Network Bridge works. You would need a desktop app that can talk DDE that could then bridge to IP/Named Pipes/WCF etc. Your NT Service would be the other end.

    As an aside the idea of a DDE2IP style bridge has become a common theme over the last few months and I hope to extend my DDE tools with such a beast over the coming months.

    P.S. Feel free to email me directly via if you want any more advice.