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?

Bord

Why is this tagged "tortoisesvn"? Am I missing something? – Huan

I thought I was being clever since tortoisesvn is the most frequently mentioned App when dealing with icon overly limitations - mostly because it takes 9 of your available slots. Removed the tag. – Bord

The limitations is still same on windows 10. Don't know why either. – Humberto

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

Huan

Excellent response. So maybe the better question is "What is an alternative to icon overlays that presents the same instant visual queue on the status of a file/folder?" It seems to me that using icons to do more than identify content type is becoming more and more important for the exact reason Raymond Chen mentions - with the blurring of file location boundaries, status MATTERS. – Bord

Thanks, I had installed and uninstalled Expandrive but it left it's icons. I just deleted those entries from the registry and rebooted. Worked fine, now my sugarsync icons are back – Oophorectomy

Great feedback @cody-gray. My major gripe is, for a long time Gnome on Linux has allowed more than 15 icons. Also it allows the users to use more than 1 at the same time, plus you can place them in different regions! – Brenna

I very much suspect that it's neither a conscious design choice nor an imposed limitation, but a fatuous design decision made a long time ago (circa Win 95), and never fixed due to installed user base. The dumbest decision is that each overlay extension can support only one icon overlay and for each file the shell asks only "applies?". It should have been that each overlay supports an array of icons, and for each file the shell asks "which icon overlay?", to which the extension might answer "I don't apply" as one option. – Clevie

Interesting that MS have embraced this by muddying my ShellIconOverlayIdentifiers registry entry with OneDrive crud as of Win10. To a developer using something like TortoiseSVN/GIT, these overlays are crucial and the fact that only one can be shown is a reason WHY. – Kepi

Of all the things Windows 10 broke, @Alex, that one is pretty far down my list. Deciding to foist OneDrive on users was clearly a decision made by the marketing department, not the shell team. No one budgeted time and money to go back and improve the shell imagelists to make it user-friendly. – Huan

This is not an acceptable answer. I know that part of it came form Microsoft itself, so, the unacceptance is for the Microsoft approach. See my example: I have synced folders of DropBox, Google Drive, Mega, OneDrive and Tortoise SVN and I would sincerely like to see all overlays correctly on all folders, but I can't because this dumb limitation. – Danettedaney

Answer 2

Excellent response on the practical issues by Cody. As to why 15 and not some other number, the limit is baked into the ImageList control itself.

Durance

Answer 3

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.

Narceine

The idea behind the overlays is that you should be able to identify the status of the object under observation "at a glance." Your plan, while creative, would require "hands on keyboard or mouse" in order to surface the information. Not that I have a better solution... – Bord

If they have to be in a flyout window, why not just put the information in the Information Bar or Preview Pane or some other place in the UI? The whole point of overlay icons is that they are actually overlaid and visible at a glance. – Huan

Answer 4

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

Crinum