Michael Abbott michael at rcp.co.uk
Wed Sep 5 17:16:07 CEST 2001

"Werner Schiendl" <ws-news at gmx.at> wrote in
news:3b9631aa$0$28956$6e365a64 at newsreader02.highway.telekom.at: 

> Hi,
>> 3. DDE has a number of potentially crippling faults, but it is quite
>> wrong to describe it as a damaging zombie.  When used correctly, it
>> works extremely well.
> On Win32 platforms (that is, everything from Win95 and WinNT upwards)
> this is not correct.
> A single running application in the system (note: ANY application in
> the system, not just the client or the server application in question)
> that does not properly process DDE messages in its message loop can
> easily BLOCK the whole DDE system and you will wait for your DDE call
> to be completed forever.
> There is an article on MSDN about that and how it is caused in detail,
> but unfortunately I do not have the number in my memory.
> Anyway, I would agree with Alex' choice of terms :-)


The problem you refer to is due to the way a DDE client establishes 
communication with a DDE server: this is done by broacasting a 
WM_DDE_INITIATE message using SendMessage() to *all* applications in the 
    	For any application with a message queue, NT handles SendMessage() 
processing by blocking until that application reaches a point where the 
SendMessage() can be processed (calling GetMessage() is one such point, but 
there are others), so any application which (perhaps unwittingly) creates 
itself a message queue but which fails to pass through SendMessage 
dispatching check points can block any SendMessage() broadcasts.

Unfortunately, SendMessage() is used elsewhere in this way, I believe.  
Also, the system continues to use DDE in places, so applications which 
cause blocking as described above can cause unexpected problems elsewhere.  

Let's not go into the details of what is wrong with Windows NT, eh?

More information about the Python-list mailing list