Re: More on Shatter

["Daniel Newby" <dnewby () nomadics com>]

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