Can you ignore DDE as a programmer on Windows? "While it was a reasonable solution back in the cooperatively-multitasked world of 16-bit Windows where it was invented, the transition to 32-bit Windows was not a nice one for DDE. Specifically, the reliance on broadcasts to establish the initial DDE conversation means that unresponsive programs can jam up the entire DDE initiation process. The last shell interface to employ DDE was the communication with Program Manager to create program groups and items inside those groups. This was replaced with Explorer and the Start menu back in Windows 95. DDE has been dead as a shell interface for over ten years."
To read all comments associated with this story, please click here.
Member since:2006-02-21
Member since:2005-09-03
Perhaps you are right in respect to initial cost of human labor; however, its is important to consider time spent updating the code when systems it depends on are modified, or the cost of fixing potential bugs or security concerns that relate to the code.
Now, I am not saying Microsoft should or should not, that is their call. But there is an advantage to removing truly superfluous code (whether DDE is, is another issue). Mainly less code complexity, which means an easier to maintain code base.
Member since:2006-07-04
IIRC, DDE began simply as a particular protocol built on top of WM_USER windows messages (I think Excel may have invented it).
Windows 3.0 "formalized" the protocol by creating WM_DDE_* windows messages. But that's it. There was still no real API support, only the WM_DDE_* constants that appeared in the Windows SDK headers, as well as the documentation for those constants. Apps still had to implement the DDE protocol on their own, as the OS itself didn't treat the WM_DDE_* messages any differently than WM_USER messages.
With NT, Microsoft created DDEML.dll (DDE Management library), which did add function support for DDE, which made it easier to implement DDE in apps (though apps could still implement the protocol on their own and pass WM_DDE_* messages around directly). But the real reason DDEML.dll was created wasn't to make it easier to implement DDE, it was to provide standard support for the WM_DDE_* messages that used shared memory. Under Win16, all memory was shared, so you could just pass a handle to memory allocated by GlobalAlloc directly on top of a WM_DDE_* message. This isn't doable under Win32, since apps have their own memory address spaces. So one has to marshal memory from one address space to another when passing the WM_DDE_* message; DDEML.dll functions do the marshalling of memory for you.
Nothing has changed regarding DDE since then, except that Microsoft did take your advice in dropping unneeded support by dropping NetDDE from Vista (NetDDE allowed DDE messaging over networks; I only ever saw it used to allow for shared clipboards which allowed pasting data copied from another machine's clipboard or some such). I've read that NetDDE was dropped for security reasons.
So, I think that DDE is stable and mature, and as such, there's no need to drop it just for the sake of dropping it. That would create problems and solve none.
Additionally, the cited blog is incorrect, when it suggests that DDE is dead. As stated in the comments to the blog, ShellExec still uses DDE to "launch" documents, if the app so indicates with its registry settings that DDE should be used. For example, HKEY_CLASSES_ROOTWord.Document.12 and Word.Document.8 show "ddeexec" shell commands that handle creating, opening, printing documents. So, double-clicking a .doc file in Explorer sends Word a FileOpen dde command. This allows a single instance of an app to handle multiple requests from the shell (or any app that used ShellExec/ShellExecEx); otherwise a new intance would be launched for every such request (which many apps *want*, particularly SDI apps, but not all apps, and even many SDI apps prefer to use DDE to handle shell requests). So Microsoft can't drop DDE because it's still used by the shell. (Microsoft *could* make ShellExec use OLE Automation commands rather than DDE (there are standard OLE Automation commands for File-Open and the like), but that would force apps that don't implement OLE Automation to do so (it's easier for apps to implement a couple of DDE commands than implement COM Automation).)
Edited 2007-02-27 03:32
Member since:
2005-07-06
How about this; kill the damn support/compatibility for it; if there companies still using it, obviously their application isn't important enough to be running today.
DDE, prime example of compatibility provided at all costs, not needed, those who use it are probably two bit companies who don't have their act together; nothing lost if it is dropped.