Why is there a limit of 15 shell icon overlays?

Raymond Chen

There is a limit of fifteen shell icon overlays. Why fifteen?

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

Another unsatisfying explanation is that the image list serialization format would be affected. This is one of the far-reaching consequences I hinted at: Changing a file format means that you also need to come up with a compatibility story. What happens if an old program encounters a file in the new format?

Okay, so maybe we leave image lists the way they are, but change Explorer so that it internally allows more than 15 overlays by, say, “paging” overlays in and out of the system image list. But this would require taking a lock during image list drawing operations, which currently can be performed concurrently. But the system image list is exposed to applications so that they can draw out of them directly, and applications won’t know about the extra serialization that applies only to the system image list. So that’s a non-starter, too.

A bigger problem is that the overlay indices are exposed to applications via the SHGet­File­Info function. If you ask for SHGFI_OVERLAY­INDEX, then the function returns the overlay index to the application, and if the overlay index is greater than 15, older applications won’t know how to draw with it.

Now, these problems aren’t completely insurmountable. For example, we could invent a new flag to SH­Get­File­Info that says, “I understand overlays greater than 15,” and if the caller doesn’t set the flag, then the function just pretends that those overlays don’t exist. The calling application doesn’t draw the icon correctly (it’s missing the overlay), but at least it doesn’t crash.

But the main reason this doesn’t get done is simply that overlays are not recommended as the way to convey metadata about a file to the user. An icon can have only one overlay, which means that if multiple overlays apply, then the system will arbitrarily choose one to show, and the others will lose.

Windows 10 takes a step away from icon overlays by moving the OneDrive file synchronization status indicator from an icon overlay to a separate Status column.

Since it’s a separate column, there’s room to put more than one status icon there.

14 comments

Discussion is closed. Login to edit/delete existing comments.

  • David Walker 0

    “Basically it boils down to “It would be a lot of work and we are lazy.”” 

    Another way to say that is “It would be a lot of work and the benefits might be less than the cost of the work”.  Laziness is not required to make a reasonable tradeoff….  

    Interesting new blog layout!

  • Lucas A. 0

    Very interesing, thanks. How can you create a column like “Status” and make it display by default ?

    PS: The link sitting in a far-away leaf branch redirects to the home page (a little dust)

    • Raymond ChenMicrosoft employee 0

      Yeah, the redirects are still a little wonky. The migration team is working on it, hoping to have a solution in a day or so.

  • Gee Law 0

    I’ll be completely off-topic.

    Think I saw the change between new/old layouts. I wonder how many of your HTML/CSS screenshots are broken because of the new layout. Personally I find the new layout less conveying — the titles are truncated on the index page. BTW I’m impressed by the energy MS invested to create the SharePoint ad…

  • Moi Me 0

    The additional column is an elegant solution.

  • cheong00 0

    As for “What happens if an old program encounters a file in the new format?”, it crashes.

    In GDI+ of Win7(Vista also?) they added support for a new way to specify the timeline of animated GIF.
    In the old way (the way WinXP supports) the value is on PropertyItem 0x5100 (FrameDuration) of the frame. The new way involves setting time value on FrameDimension.Time.

    Try resizing animated GIFs with new method then open the generated GIF on application WinXP cause it to crash. (The same application running on Win7 has no problem)

    • David Walker 0

      Yes, many things likely don’t work in WinXP.  Or in Windows 3.1 either….  Technically those are operating systems, not applications, but the operating systems had default applications for displaying GIFs. 

  • Ralf Berkvens 0

    I know you probably can’t do anything about it Raymond, but I’ll say it anyway: the ‘load more’ button at the botom of the comments is visible even when there are no ‘more’ comments to show.

  • Ralf Berkvens 0

    Also, the comments are sorted the wrong way around (new to old, which does not really help when trying to follow what people are saying), and there seems no way to sort them the other way around. (And I get a script error when I post a comment, something about grecaptcha not being defined).

  • Guillaume Dube 0

    Ah, I like the column solution better as well. Did your team give them this advice, or did they come to it themselves? Now I hope Dropbox does it as well.

  • Felix Becker 0

    How can the user see the status though if they don’t use the “details” view, but e.g. “large icons” (as for folders that contain pictures)?

  • Kristian Buchholtz 0

    Is it planned to provide 3rd party dev’s like Dropbox, TortoiseGit, etc. access to the new Status column? Would be greater, if other dev’s could use that feature too. 

  • Basanta Kharel 0

    Thanks Raymond, for at least giving us some explanation about the design
    You mentioned that OneDrive started using a separate column for status, but did you know that this is only when On-Demand option is turned on?
    If it is off, it still uses overlay icons, 7 of them, in the latest update.
    Also do you have any recommendation for older version of windows, like windows 8.1 ?

Feedback usabilla icon