ShellIconOverlayIdentifiers - why so few?

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?

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".

Excellent response on the practical issues by Cody. As to why 15 and not some other number, the limit is baked into the [ImageList](http://msdn.microsoft.com/en-us/library/bb775227.aspx "ImageList_SetOverlayImage function") control itself.

This is all very well and good, as explained by Cody Gray, but frankly it is pretty unimaginative, and as reported behind the scenes, sounding a bit frustrated.

In 2015 and with Windows 10, surely there can and needs to be a better ability, as I noted about thirty overlays present and had to prioritize ones I wanted most to see, which is not what you want most people to worry about at all. Also I see aggressive vendors like Box over-competing to try to prioritize themselves, and that will never go any place good.

Here's a possibility: What if multiply overlaid icons had a generic overlay indicator; a small rectangle matrix of multiple colors like the Google Chrome Apps button? Singly overlaid would just show the overlay out of a long list.

Then when the mouse pointer meets the icon, a small flyout window collects all the icon variations to view (at small icon size or a little larger). Each overlaid icon in turn announces by tooltip what it is, when you mouse over.

Now you can have all the icon overlays you need, for state in various clouds, for repository indications as for Tortoise tools, and so forth.

I quote an extract of the definitive answer here from Why is there a limit of 15 shell icon overlays? Raymond Chen 2019 post

> The value 15 came from the corresponding limit for image lists. The > Image­List_Set­Overlay­Image function supports up to 15 image list > overlays per image list. (Hey, it used to be worse. The limit used to > be only 3!) > > Okay, but why only 15? Why not more? > > The overlay image is one of the pieces of information used when > drawing an image from an image list. The options are encoded in the > fStyle parameter, and when the bits were divided up for various > purposes, four bits were available to be used to specify the overlay > image. (You get 15 overlay images instead of 16 because you lose one > of the values in order to specify “no overlay.”) > > Okay, but the values in the fStyle parameter use only the bottom 16 > bits. What about the upper 16 bits? There’s plenty of room there. > > The 16-bit limit was carried over from the 16-bit version of the > common controls (which still needed to be supported in Windows 95). Of > course, nowadays, nobody cares about the 16-bit version of the common > controls, so why not start using the upper bits? > > There’s an unsatisfying explanation: The code internally that manages > the fStyle still uses a WORD in some places, so all the code that > manages the fStyle would have to be revised. This occurs in multiple > modules across Windows, so a synchronized change would have to be made > across multiple components. This is a breaking change at the binary > level because the interfaces are no longer compatible. Breaking > changes are procedurally difficult to coordinate: The affected code > may not be visible to the shell team because they are sitting in a > far-away leaf branch that has not yet RI’d to the trunk. It might be > that expanding fStyle from a WORD to a DWORD has far-reaching > consequences for some component. > > Like I said, this is unsatisfying. Basically it boils down to “It > would be a lot of work and we are lazy.”