dde?

Alex Martelli aleax at aleax.it
Wed Sep 5 18:29:58 CEST 2001


"Michael Abbott" <michael at rcp.co.uk> wrote in message
news:Xns9113A5D55CB87michaelrcpcouk at 194.238.50.13...
    ...
> 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

Right -- in the sense that this is the way DDEML does it (I do
agree with you that DDEML is a lot of what's wrong with DDE:-).

Of course, a *sensible* programmer would ALWAYS use
SendMessageTimeout for broadcast, NEVER bare SendMessage --
but, alas, DDEML's broken, and it's _never_ gonna be fixed
(DDE's Microsoft's baby, MS has decided years ago that DDE
was dead, which is what justifies my calling DDE a zombie:-).

> system.
>     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.

Right -- which is why one ALWAYS uses SendMessageTimeout when
broadcasting.  Would you do a select() call on Unix without a
timeout parameter unless you had TOTAL trust in every other
application that might be possibly handling the sockets/fd's
you're selecting on...?  The issue is quite similar, except
that using HWND_BROADCAST *ensures* you can never "have TOTAL
trust" in whatever:-).


> 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?

Not the fact that it ALLOWS you to do blocking calls -- it allows
reasonable non-blocking/timeing-out alternatives, after all.  Rather,
one could point the finger at the fact that its sources are not
available for fixes, so that *obvious* oopses like using blocking
calls where non-blocking ones should be used can't be fixed unless
MS decides it WANTS to see them fixed:-) -- if for strategic
reasons MS prefers to kill DDE, you're SOL:-).

I'm not aware of other "system" places doing SendMessage broadcast
without timeouts, in modern NT versions (say 2000 SP2 and later),
except for DDEML and its users, though I'd welcome any news in
the matter (since I do have to keep doing "system programming",
or what passes for it, on NT/2000/XP, no matter how much I prefer
BSD or Linux variants:-).

Of course it's better for an app to service its message loops --
it's quite OK by me if the system chooses to deem apps that DON'T
serve their message loops to be "dead, crashed, errant or maybe
malignant" and kills them on the spot after a reasonable timeout.

But just in case a given machine is NOT running such a nice
background "weeder of zombies" daemon, oops I mean service, I'd
also much rather my OWN apps didn't stop in their tracks when
such a beast is present:-).


Alex






More information about the Python-list mailing list