I don't want to belabor this issue, but I strongly disagree with the
pronouncements that the problem is "inherent to the Win32 API" and "unfixable".
At 03:33 PM 8/23/2002 +0000, Dragos Ruiu wrote:
>Filtering and lookups in tables can be computationally
>intensive tasks. And parsing every message to weed
>out some is not only potentially slow, but could be
>a cure worse than the disease... because it might
>break potentially sloppy code in some critical app...
I've been out of the Win32 scene for a couple of years, so I talked with my
Win32 colleagues to find out exactly how WM_TIMER is used. According to
them, WM_TIMER is usually used for low-precision user interface stuff
(e.g., timing for tool tips). A typical application has perhaps half a
dozen of these timers active at once.
The overhead of checking half a dozen pointers ought to be negligible
relative to the substantial overhead of the message queue. Rejecting
WM_TIMERs from other processes would be even faster.
As far as breaking code goes, the security patch should be
configurable. Operators of critical servers could leave the filtering
turned off to minimize surprises. Operators of terminal servers and
public-access computers could turn it on to keep untrusted users from
running amok.
>The added latency might be a serious issue in a time
>critical place like a *timer* service (or message) routine.
WM_TIMER messages are processed at a low priority: the message queue has
to be empty of everything else (mouse movements, keyboard messages, etc.)
before a WM_TIMER will be processed. Windows has other timers (e.g., the
multimedia timers) for applications that need precision timing.
>Yep, this is a hard problem. The real solution is not to
>pass the call back in this way, but such is the curse of the
>pre-defined API you have to maintain backwards compatibility
>with. Maybe another few hundered MB of code might fix
>it? :-) Probably not. If it's any consolation there are some
>similar locked into stone API architectural issues in
>things like POSIX too that ought to be fixed but
>cannot while retaining backwards compatibility - though
>perhaps not of this magnitude of impact.
My colleagues tell me that using the callback is poor technique
anyway. It's just as easy to manually handle the WM_TIMER message when you
process the message queue.
>As much as it seems easy to bash MS for this one, it isn't
>their fault some applications are lame :-).
Yes it is. The "feature" is useless, surprising, and makes it easy to
shoot yourself in the foot. A skilled software engineer may be able to
work around it, but it's still a flaw for the average programmer.
>Though it seems
>to me they *should* fix the default handler for WM_TIMER
>in DefWindowProc() to avoid the arbitrary callback use but
>I don't know enough to say whether this too would break a
>lot of stuff since someone at MS who probably knows more
>about this seems to think this is a bad idea.
I bet this is why a patch hasn't been forthcoming. They have to make it
configurable for people who can't accept breakage, the gradations of
breakage have to be carefully chosen for different user environments, and
then it has to be regression tested against zillions of apps. (Hopefully
I'm not giving them too much credit...)
-- Daniel Newby, speaking for myself
This archive was generated by hypermail 2b30 : Sat Aug 24 2002 - 09:43:48 PDT