AutoHotkey Community

What is DDE and why is it totally different from COM?

DDE stands for Dynamic Data Exchange. That's exactly what it does, and nothing more. It sends data between applications using Windows messages according to a documented protocol. Saying that DDE is old-fashioned and is being replaced by COM is something you see repeated parrot fashion over and over again. DDE and COM do not work in the same way and they solve different problems.

Here are some points of difference:

- COM is synchronous, one party makes subroutine calls into the other and must wait until the call returns. If the called component is busy the caller is blocked until it becomes free. DDE is asynchronous, a well-programmed client sends a Windows message to the server and carries on processing. Windows holds the message and sends it to the server when the server is ready to process it.

- COM is complex to program but powerful. The client can manipulate objects within the server as if they belonged to the client. DDE is straightforward to implement but all it can do is transmit data. It can only control another application because the recipient can treat data as a command.

- COM works well when the client creates an instance of a server object or application for its own use. Programming a continuously running server, to which clients can attach when they wish, is possible but tricky. DDE of itself is incapable of creating objects (although OLE1 used it as a transport mechanism). The essence of DDE is that clients attach to an already running server.

- Applications using COM almost always need support DLLs such as the VB runtimes or MFC. Programs using DDE can be mean and lean and do not need extra support DLLs.

- COM interfaces are tightly specified and contained within the software component. Some documentation is normally built into the interface. The user of a COM component knows exactly which methods are available and how to call them. DDE interfaces are specified only in external documentation.

- Because of the tight interface specification, upgrading COM components can be a nightmare. With DDE the server or client can be changed independently.

- COM is frequently used to communicate with a DLL in the same process space (called an in-process server). Such as server is often termed an ActiveX control and has the extension OCX. Our DDClient and DDServer Visual Basic components are in-process servers. Using DDE to communicate between components of the same application is possible but has no benefits.

- COM communication with a remote machine is called DCOM (Distributed COM). If you make a DCOM call to a remote machine which does not respond, your program (or at least the thread making the call) is stuck. DCOM has a fixed built-in timeout which you cannot change. DDE with a remote machine is called NETDDE, it is used by the Hearts game and Chat which come with Windows. Timeout is controlled by the program.

- Under Windows 3.1 and 9x it is possible to crash the system by badly programmed DDE, because the message queue can be filled. NT does not crash in this way, COM does not suffer from the problem at all.

- DDE is totally "Bit blind", neither the client nor server can tell whether the other application is 16-bit or 32-bit. Indeed, the server cannot know whether the client is on the same computer or not. Connecting 16 to 32 bit COM components is not usually possible.

It is easy to see from the above points why a DDE server is the most widely used way of providing data obtained from any form of hardware interface.

In particular:

- The server can run continuously.
- It will probably serve a wide range of clients but can be updated without requiring them all to be recompiled.
- It is immune from the problems associated with different versions of the system DLLs on different machines.
- It can be small and self-contained.
- Clients cannot interfere with the running of the server by being slow or busy.

Yes, COM support is tentatively planned. It is a relatively low priority because:
1) At a guess, probably less than 1% of AutoHotkey's users would use it.
2) It seems hard to implement, but that's probably because I know so little about it.

ddedll.zip
ddehot.zip
ddeml.zip
ddesys.zip

DDE Sample Source code and information

ddeole.zip

DDE/OLE information and sample source

ddeser.zip

Sample DDE Server