[iforgotpassword]

Indeed a great read to catch up with the project.

> Talking about the notification tray, due to Ged’s work, icons of killed and finished process are now automatically removed, even when apps crash. This is something that Windows doesn't even provide with Win10, and many Windows users may have noticed.

Made me chuckle. This has bothered me since forever. It seemed like such a low hanging fruit to fix, I wonder why Microsoft never did.

[fluxsauce]

> I wonder why Microsoft never did.

I'm assuming it's because of the size of the codebase, available engineering resources, return-on-investment calculation, and a business prioritization of new features over refinement.

Most engineers can look at their own work or codebase and think, "well, that's a bit shit but it works well enough." I can't imagine their backlog. I'm sure it's lurking in an issue queue somewhere.

[dfox]

One notable thing is that in Windows the behavior of taskbar changed around the time of Windows 98SE/2000 (I'm not sure in which version exactly). Originally the "orphaned" tray icons just were there and you could not cause them to go away, "new" behavior is that first event (ie. hover) causes them to be destroyed.

[mschuster91]

Guesswork: once you hover over an icon in the taskbar, later Windows checks if the process (or, rather, window, as the icon will be tied to the window handle you get from CreateWindowEx) handle belonging to it is still alive. If not (aka it cannot find a target window to send the message to) the icon gets destroyed.

ReactOS, another guess here, does either a polling check if all taskbar icons have valid process handles or a check whenever a process exits.

[dfox]

AFAIK the taskbar forwards the window messages destined for the icon to window that owns the icon and in the "new" Windows' behavior simply notices that such window does not exist. ReactOS behavior probably works on the basis of hooking destruction of the owner window (although I suspect that on Windows windows owned by killed process will not get WM_DESTROY message, but it's wild guess as I'm completely out of my rudimentary and rusty knowledge of WinAPI there).

[tinus_hn]

The notification area API sucks because of considerations made 20 years ago. The icons aren’t windows, the application just sends bitmaps to show and is manually notified if you hover over or click on an icon.

Explorer can’t tell if the app connected to an icon crashed without polling or other tricks which Microsoft probably wants to avoid. But it can tell if you move the mouse over them and it can’t send the messages to the application.

Also the notification area with a million icons is bad UI that I can imagine Microsoft not wanting to invest in. They tried to discourage its use by hiding most of the icons all the time.

[userbinator]

The reason could be stated in one word: "architecture", or perhaps less positively, "bureaucracy". In other words, either they could've designed it originally in such a way as to make fixing such a bug very difficult to do without rewriting massive amounts of code, or the fix could be simple yet the politics around actually getting that fix into code are not.

Having worked at large corporations (not Microsoft) before, I can definitely see how things like this happen --- and the reason why "enterprise" software tends to have a lot of these superficially simple and annoying defects. To add insult to injury, the codebase is often offensively overengineered and in precisely the wrong direction to facilitate the change required to fix such bugs, and even the tiniest of changes requires a ton of extra paperwork, approvals, and reviews.

[gambiting]

Vista and 7 had a well known bug where a contextual window would stay on screen forever, until you changed the resolution or logged out - I think Microsoft commented on this officially, saying that fixing it would need to be done somewhere low at the kernel level and it's simply too much work. I think it was resolved fully in 10.