ShellIconOverlayIdentifiers - why so few?

Question

At this point, everyone knows that there's a limit to the number of ShellIconOverlayIdentifiers (from MSDN):

The number of different icon overlay handlers that the system can support is limited by the amount of space available for icon overlays in the system image list. There are currently fifteen slots allotted for icon overlays, some of which are reserved by the system. For this reason, icon overlay handlers should be implemented only if there are no satisfactory alternatives

I can understand the 15 overlay limt in Windows 95. But in an environment where there's Gigs of RAM, numerous Cores, and GPUs, is there some technical reason for such a low number in a modern operating system?

And why isn't this value configurable?

Before giving the 'performance' answer, consider: Windows allows for configuration such that you can kill performance... why pick on this issue specifically?

Answer 1

Unless someone here happens to work on the Windows Shell team, I doubt that you're going to get an answer that really addresses the technical limitations and how they affect the design choice. But I'll try...

My guess is that there isn't any technical limitation, or at least there isn't one now. The real reason is presumably that no one has ever taken the time to sit down and update the code, the design, and the spec to lift this limitation. Features aren't implemented by default, and just because the computing environment has changed in the last few years doesn't mean that someone sat down and rewrote Windows to take full advantage of all those changes.

You should also consider that is more than likely a conscious design choice, rather than an imposed limitation. Raymond Chen (who actually does work on the shell team) published a blog entry responding to the uproar about Windows 7 removing the "sharing hand" overlay. He makes a compelling argument that the icon overlay is really not a desirable way of showing information (above and beyond the fact that the system is limited to 15) [emphasis added]:

Generally speaking, overlays are not a good way of presenting information because there can be only one overlay per icon, and there is a limit of 15 overlays per ImageList. If there are two or more overlays which apply to an item, then one will win and the others will lose, at which point the value of the overlay as a way of determining what properties apply to an item diminishes since the only way to be sure that a property is missing is when you see no overlay at all. (If you see some other overlay, you can't tell whether it's because your property is missing or because that other overlay is showing instead of yours.)

It seems reasonable to me that the extra clutter added to the shell is simply not worth it in the majority of real-world cases. The Windows Shell team obviously reached the same conclusion and cut the "sharing hand" overlay. Raymond's direct explanation:

Given the changes in how people use computers, sharing information is becoming more and more of the default state. When you set up a HomeGroup, pretty much everything is going to be shared. To remove the visual clutter, the information was moved to the Details pane.

And, I know you specifically asked not to mention performance, but Windows really does try to keep you from shooting yourself in the foot. Users demand responsiveness in the shell, and overlay icons can interfere with this. As further evidence that they are not the priority, another blog post by the same Raymond Chen chastises:

Another example of applications having a selfish view of performance came from a company developing an icon overlay handler. The shell treats overlay computation as a low-priority item, since it is more important to get icons on the screen so the user can start doing whatever it is they wanted to be doing. The decorations can come later. This company wanted to know if there was a way they could improve their performance and get their overlay onto the screen even before the icon shows up, demonstrating a phenomenally selfish interpretation of "performance".