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.”
Er, Isn’t DDE still used BY Explorer?
As far as I’m aware, it’s the reason why you can get ‘Explorer cannot find…’ error messages after successfully launching a program (i.e., a DDE timeout occurs).
“Er, Isn’t DDE still used BY Explorer?
As far as I’m aware, it’s the reason why you can get ‘Explorer cannot find…’ error messages after successfully launching a program (i.e., a DDE timeout occurs).”
No, it isn’t. Google DDEspy
please feel free to stop using punchcards…
For a dead tech I sure had no issues with some legacy software which uses DDE. Communications between the two programs using DDE went off without a hitch.
For *talking* to explorer I wouldn’t use it, and honestly I can’t think of a reason to use it in a new app (COM and .net single remoting objects provide a better mechanism, heck even sending registered messages via sendmessage works better) its nice to know it works for legacy applications.
i like how the first 10 comments on that site have to do with the car metaphor.
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.
No, ripping out code that is doing no harm to Windows would cost more than to just forget about it being there.
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.
True, and with each successive generation of Windows, it has to be hauled along, maintained, updated to make it compatible with API changes further down the chain – it all costs money.
As for should they drop compatibility; given that the need to use it was killed over 10 years ago, I hardly, see the requirement for continuing on something that should have been dropped from code bases for many companies long ago.
This is how Apple keeps their costs low; when they kill something off, they depreciate it, remove the ability to compile against it, then they finally remove it; Microsoft has given companies 10 years to remove that piece of functionality from their application – and the best thing for Microsoft to do? not *only* remove it, but if there are any applications out that rely on it, and Microsoft can provide an alternative to it, then they should off those affected customers a free upgrade to the Microsoft version of the said application.
then they should off those affected customers a free upgrade to the Microsoft version of the said application.
pfff…
why pff?
If I was in Microsofts place and the competition fails to update/upgrade their software so their customer can continue on using the new operaitng system, that would be the perfect opportunity to swoop in and take marketshare off companies who are failing to serve customers needs.
If Microsoft really want their XPS format to replace PDF, then they should provide themselves clients for Linux, FreeBSD, Solaris, Windows, PalmOS, MS Mobile OS etc. etc. If Adobe is going to fail to serve customer needs by their Anti-UNIX (including Linux) agenda, then Microsoft should swoop in and take the marketshare off Adobe.
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
DDE was a somewhat kludgy design, squeezing data through such a narrow pipe. But it worked when all else failed. Also, it did not carry the tremendous overhead of OLE. Similar to using a scripting language, if you needed some functionality fast and cheap, DDE was a way to deliver it.
That article, and one linked to it, talk about dropping DDE and the concept of message passing in your applications. However, a huge number of applications use WM_ message passing, and if you’re doing something such as trying to change the colour of a listview item, or sub item, for example, then you’ll be using Custom Draw and trapping WM_ messages. Even in .Net.
Edited 2007-02-27 11:07
That article, and one linked to it, talk about dropping DDE and the concept of message passing in your applications. However, a huge number of applications use WM_ message passing, and if you’re doing something such as trying to change the colour of a listview item, or sub item, for example, then you’ll be using Custom Draw and trapping WM_ messages. Even in .Net.
Err…DDE and message passing in general are two different things. DDE is handled inside the application via messages, but that is not specific to DDE; every (non-cmdline) application uses messages. Where in the article did it say anything about dropping the concept of message passing?
Where in the article did it say anything about dropping the concept of message passing?
Have a look at the article, and the one it links to called the reliance on broadcasts.
I know this is slightly off topic, but:
Have anyone ever tried to use DDE in a Gtk+ Application on Win32 to have the single-instance handling documents opened by ShellExec ?
I tried accomplishing this for a project I was helping once and never got any good documentation on how to.