DomainID<>WimpTaskhandle / FilterManager issues

I’ve noticed the Wimp Taskhandle is slightly different from the DomainID, does that mean more than one Task can be associated with a DomainID?

I’m trying to figure out the cleanest way of removing Filters from a Wimp task when the task closes without calling Wimp_CloseDown. I’m using Service_WimpCloseDown to determine in the task is one associated with a domainID ADFFS is managing, so Filters are removed when the domainID dies.

…which leads me on to the root cause of why I have that issue in the first place. Filter manager isn’t removing filters associated with explicit tasks when they close, leaving it in an odd state. It appears to fall over as soon as it hits a Filter that’s associated with a task that no longer exists. *Filters also returns a truncated list of filters, stopping as soon as it reports a Filter has no task.

Task handles are actually 16bit numbers.

The Wimp decorates them with a cycle number in the top 16bits so that when one task ends and another starts and is given the same handle, other tasks don’t mistake it for its predecessor.

I’m not sure if it’s documented (ha!) that you should mask off the top 16bits when comparing task handles in Filter handlers.

As for your other issues, I’ll have a play.

Filter manager isn’t removing filters associated with explicit tasks when they close

You’re right of course. And as FilterManager only has the undecorated task handle, it will falsely match a new task.

For example, my PublicFilter module filters three Filer icon tasks. I just killed ShareFS and then ran Paint, and…

As it happens I was looking at FilterManager very recently, and it’s very very simple.

Inexplicably it only responds to Service_WimpRegisterFilters, and not Wimp_CloseDown (which it obviously absolutely has to).

This is a bad bug, and the fact that it doesn’t seem to be widely known indicates exactly how often filters are used, evidently.

Perhaps the filter owner is expected to spot the closedown… but it’s an omission, and a dangerous one. I’ll write it up.

Perhaps one of the OS developers could confirm if this is or isn’t a bug.

It certainly looks like one to me as I’d expect FilterManager to both ensure task specific filters are only assigned to that task and are removed if a task quits.

It’s a feature not a bug – it doesn’t attempt to handle tasks that have quit, other than by displaying the task handle in hex if it can’t look up its name.

It is not a useful feature and should be retired. I have a prototype.

Could any software be relying on this ‘feature’ ?
With my limited understanding I’d not expect it. But my experience tells me stranger things are out there!

I’d think not. After all, the task handle of the task that has quit (resulting in a flailing filter flapping about) will be reused, but not necessarily by the next new task – it would depend on how many other (non-filtered) tasks have quit.

So one couldn’t even argue that task-quit, task-run would be expected to result in the same (undecorated) task handle… it ain’t necessarily so.

It’s a misdesign and a vulnerability.

Could any software be relying on this ‘feature’ ?

Change it in the beta build, and see what (if anything) blows up.

It’ll surely break less things than ZPP did. ;-)

It’ll surely break less things than ZPP did.

I believe you mean “It is less likely to point out broken items of software than ZPP did”
All ZPP did was fix a hole and ZeroPain was the illuminated sign for the diversion round the hole that lit up with “wrong way”.

I’ve seen numerous examples of programs on Windows where security fixes stopped the program working because it actually relied on the security hole existing to function.
Programmers make daft decisions daily (or more often perhaps).
I’m waiting for the change that stops programs like Cisco ASDM¹ from storing stupid amounts of cached settings information etc in the users roaming profile.

¹ Or the e-reader available from the Cisco training site that thinks the best place to store your reading material is in the… users roaming profile. No, the two items don’t have a nice handy config item marked “store cached files here:”, Yes, I’ve communicated with Cisco on the subject and I expect even less of a response than we had to the serious, show stopping, fault that appeared in Cisco ISE² that took them 12 months to fix – admittedly the first 8 they didn’t actually do anything other then help maintain the work around which was to supply us with a “Plus licence” for a limited period which was repeated and repeated and repeated…

storing stupid amounts of cached settings information etc in the users roaming profile.

The one time I tried the Chrome browser, and realised where it installed itself (hint, it was not Program Files) is the time I erased it and vowed never to touch it again.
The install location (AppData) is justified as “The good thing about installing Chrome in AppData folder is it doesn’t require UAC elevation so any user including Guest account will be able to successfully install without problems.” Now doesn’t that sound like “we think we’re more important than your system security”? When would somebody appreciate a Guest level user installing a major (Chrome ain’t small) package? If the user was to install stuff, they’d have that privilege…

I believe you mean

All the way through, I’ve been looking at it from the perspective of an end user. I’m a geek, I understand ZPP, I understand null pointers. But also I understand “this program has worked for a decade and now a change in the OS broke it” – which is why I was quite vocal about the need for what we now have – the “carry on blithely unaware compatibility page”. Because while we might enjoy pulling apart stack dumps to work out what just blew up, some people just want the thing “to work” especially if said software is no longer being maintained. And, yes, I also understand the argument that said software is bugged and technically broken, but if it’s worked since the Iyonix, that’s good enough… Let’s leave the job of actually breaking software to ARM architecture changes. :-)

Could any software be relying on this ‘feature’ ?

I don’t think anything will be relying on FilerManager blowing up when it comes across a Filter assigned to a non-existent task. As for the other issue of it assigning said Filters to newer tasks if they get the same taskID, that should not be an issue either as FilerManager has always had “all tasks” Filters, so it’s unlikely someone would code a Filter to be assigned to a specific task and then by luck test it and find it’s also assigned to a later task and their code work.

I’ve prototyped the fix and it works nicely:

Note that the orphaned filter is shown with a taskname of [-----] just to confirm that it is not operational – it’s actually the event mask of FFFFFFFF that renders it ineffective. All filters that take a task handle now check the event mask, even where previously they did not.

Such orphans could be suppressed entirely from the output of *Filters, but I wanted to monitor the behaviour (and oooh *Filters is terribly written).

As previously mentioned, the filter can’t be discarded when the target task quits, because the filter owner may try to deregister it later, and we don’t want to generate an error where previously we did not. The event mask is not used for filter matching so won’t affect that.

Also note that it is still possible to have filters attached to tasks that TaskManager is unaware of (and hence *Filters will show the task handle as a number because TaskManager cannot supply the name). It is straightforward to have tasks running that TaskManager doesn’t know about, though not to be encouraged. Filters for such clandestine tasks are not affected by this change.