ShellIconOverlayIdentifiers and windows10

Question

Icon overlays are becoming an annoying problem for me. On windows10 it seems like you can have 11 (or is it 10?) overlay icons set, others are ignored. This is very low number that is easily used even by one service.

So windows just takes first N settings as by alphabetical order which started the following petty trend.

This is my registry:

As you can see, companies started adding spaces to get to the front of the order. In recent update dropbox added third space already!

Question: 1) Is there a way to use something else than alphabetical order to tell windows which N settings (as much as windows supports) to use?

2) Is there a way to increase the number of identifiers in effect?

Answer 1

No, there is no way to increase the 15 Icon Limit, this is a Limitation in Windows for years.

Every image list includes a list of indexes to use as overlays. An overlay is an image that is drawn transparently over another image. Any image currently in the image list can be used as an overlay. You can specify up to four overlays per image list. This limit has been expanded to 15 in version 4.71.

So the limit is in Comctl32.dll and we can't fix it. The overlay handler are loaded by the order of the ASCII code. So adding more paces loads them earlier. I delete the Dropbox 5- 10 icons + TSV4 + 5 because I don't use locking. I also don't use Onedrive, so I have a max of 15 overlays.

It looks like Microsoft noticed the demand of more icons and Raymond Chen wrote some details about the issue:

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.

So it is an historic limit and changing it can break other components beside the Windows shell.