Isn’t DDE all asynchronous anyway?

"Isn't DDE all asynchronous anyway?" asks commenter KaiArnold.

It's mostly asynchronous, but not entirely.

You can read about how DDE works in MSDN, but since it seems people are reluctant to read the formal documentation, I'll repeat here the points relevant to the discussion.

The DDE process begins with a search for a service provider. This is done by broadcasting the WM_DDE_INITIATE message and collecting the responses. Each server that wishes to respond to the request sends back a WM_DDE_ACK message. The DDE client then chooses which of the servers it wishes to continue the conversation with (possible more than one). The remainder of the DDE conversation is carried out with posted messages, the details of which are not important here.

As you can see, everything in DDE is asynchronous with the exception of the WM_DDE_INITIATE. Why is WM_DDE_INITIATE synchronous?

Remember that DDE was developed back in the 16-bit days, when it was safe to broadcast messages. The initiate message and its WM_DDE_ACK replies are synchronous to ensure that the client doesn't have to wait indefinitely to build a list of servers. If it were asynchronous, then the client would post the WM_DDE_INITIATE and then wait "a while" to see if anybody responded. But how does it know when it should give up waiting and just go with whatever it has? What happens if a response comes in after the client already proceeded based on the assumption that that server was unavailable? What if a response comes in five minutes later, when the client had started a second DDE discovery query? Would that response have been to the first or the second discovery broadcast?

In particular, it is important for the client to know whether there are any servers out there at all, because the way the shell interprets DDE-based file associations is first to attempt a WM_DDE_INITIATE with the application and topic specified in the registration. If no server is found, then it launches the server manually and then tries to connect to the server via DDE a second time. (The second time should work, since the responsible server was explicitly launched!)

Comments (12)
  1. Peter Ritchie says:

    One of the many reasons why there are now alternatives to DDE for application programmers.

  2. Been there/Done That/Escaped From It says:

    My first windows project (back when 3.0 was released) was to write a DDE server. Back then being DDE-compliant meant that you worked successfully with Excel – all others were hit-or-miss. Most implementations sucked and the amount of weird issues were enormous. I vaguely recall some problem with DDE_TERMINATE and when you could close/delete the windows used in the conversation.

    I remember needing to disassemble NETDDE to figure out some problems – it was buggy too.

    The surprising thing was that if you used a good custom protocol/data format the performance was actually not bad at all. Posting a message between windows is fairly efficient (and still used in many cases); the usual performance killer was the data format. Of course the protocol as awful in many other ways, but it was useful for getting people used to the notion that applications had useful things to say to each other.

  3. DDE: old or new? says:

    As an application programmer, can I really ignore DDE if I need to interact with explorer/shell?

  4. Ben Cooke says:

    I’m sure there’s somewhere I could look up the answer to this, but I admit it: I’m lazy.

    After the shell has launched the application that provides the DDE server, how does it know when that app is ready to respond to the DDE broadcast? Does it just keep sending out WM_DDE_INITIATE every n seconds until something answers? What if it’s misconfigured and the launched app doesn’t provide a DDE server at all?

    (As you can probably tell, I managed to avoid ever learning about DDE!)

  5. Christian says:

    I hate DDE. I wished all programms just launch by looking up the file-association and starting that programm. If the programm launches an second instance: GREAT! I just want that.

    If the programm has some kind of fear of running twice: It shall take care of that problem itself and find it’s existing process and transfer execution to it.

    Not that it can do anything against that happening anyway.

    Wouldn’t it be possible to create a tool that walks through the registry and exchanges all the DDE-stuff with just launching the EXE-file and passing the data file as first command line parameter?

    I feel this would make my computer much more responsive!

  6. Brian says:

    I doubt that would make your computer any more responsive.  Applications have quite a bit of overhead involved in launching, much more than the overhead involved in DDE.

  7. Chris Becke says:

    @Christian: If you want to make your computer more responsive, find and eliminate the apps that dont respond to broadcast windows messages quickly.

  8. Carlos says:

    "As an application programmer, can I really ignore DDE if I need to interact with explorer/shell?"

    If you’re targetting Windows XP onwards you can use IDropTarget:

  9. Magnus says:

    The MSDN page linked to with "interprets DDE-based file associations " is a bit out of date and should be updated, it says nothing about per user registered verbs.

  10. DS Guy says:

    What about the environment variable SRDDE that is mentioned here?

    It appears this makes DDE synchronous if you’re using DDEML.DLL

Comments are closed.

Skip to main content