ShellIconOverlayIdentifiers-为什么这么少？

在这一点上，每个人都知道ShellIconOverlayIdentifiers（来自MSDN）的数量是有限制的：

系统可以支持的不同图标覆盖处理程序的数量受系统映像列表中可用于图标覆盖的空间量限制。当前有15个插槽用于图标覆盖，其中一些由系统保留。因此，仅当没有令人满意的替代方案时才应实现图标覆盖处理程序

我可以理解Windows 95中的15个重叠式限制。但是，在存在RAM，大量内核和GPU的情况下，是否有一些技术原因导致现代操作系统中的数量如此之少？

为什么不能配置此值？

在给出“性能”答案之前，请考虑： Windows允许进行配置，以便您可以杀死性能...为什么要专门选择此问题？

除非这里碰巧有Windows Shell团队的工作人员，否则我怀疑您将获得真正解决技术限制以及它们如何影响设计选择的答案。但我会尝试...

我的猜测是没有任何技术限制，或者至少现在没有任何限制。真正的原因大概是没有人花时间坐下来更新代码，设计和规范来消除这一限制。默认情况下未实现功能，仅仅是因为计算环境在最近几年中发生了变化，并不意味着有人坐下来重写Windows才能充分利用所有这些变化。

您还应该考虑，这很可能是有意识的设计选择，而不是强加的限制。Raymond Chen（实际上在Shell团队中工作的人）发布了一个博客条目，以回应有关Windows 7删除“共享手”覆盖物的传闻。他提出了一个令人信服的论点，即图标叠加实际上不是显示信息的理想方式（超出了系统限制为15个的事实）[强调添加]：

一般来说，覆盖不是一种很好的信息呈现方式， 因为每个图标只能有一个覆盖，每个ImageList最多可以覆盖15个覆盖。如果有两个或多个应用于某个项目的叠加层，则一个将获胜而另一个则会丢失，这时，作为确定对项目应用哪些属性的一种方法，该叠加层的值会减小，因为唯一的确定方法是当您根本看不到任何重叠时，就是缺少属性。（如果看到其他叠加层，则无法确定是因为缺少属性还是因为显示了其他叠加层而不是您的属性。）

在我看来，在大多数现实情况下，添加到外壳上的额外杂物根本不值得。Windows Shell团队显然得出了相同的结论，并削减了“共享手”的标记。雷蒙德的直接解释：

鉴于人们使用计算机的方式发生了变化，共享信息越来越成为默认状态。当您设置家庭组时，几乎所有内容都将被共享。为了消除视觉混乱，将信息移至“详细信息”窗格。

而且，我知道您明确要求不要提及性能，但是Windows确实确实试图阻止您脚踏实地。用户需要外壳中的响应能力，并且覆盖图标可能会对此产生干扰。作为进一步的证据，它们不是优先考虑的问题，同一位Raymond Chen的追随者在博客中写道：

具有自私的性能视图的应用程序的另一个示例来自开发图标叠加处理程序的公司。Shell将覆盖计算视为低优先级项目，因为在屏幕上显示图标更为重要，以便用户可以开始执行他们想做的任何事情。装饰可以稍后再来。该公司想知道是否有一种方法可以改善性能，甚至在图标出现之前就将其覆盖在屏幕上，从而展示出对“性能”的一种自私的解释。

科迪对实际问题做出了出色的回应。至于为什么15个而不是其他一些数字，该限制被放入ImageList控件本身中。

正如科迪·格雷（Cody Gray）所解释的那样，这一切都很好，但坦率地说，这是完全没有想象力的，而且据幕后报道，听起来有些沮丧。

在2015年和Windows 10中，肯定可以并且需要有一个更好的功能，正如我注意到存在的三十个叠加层，并且必须对我最想看到的叠加层进行优先级排序，这并不是您希望大多数人担心的。我还看到像Box这样竞争激烈的供应商过度竞争以试图确定自己的优先级，而这永远不会有任何好处。

这是可能的：如果多重覆盖的图标具有通用的覆盖指示符，该怎么办？像Google Chrome Apps按钮那样的多种颜色的小型矩形矩阵？单独覆盖将只显示长列表中的覆盖。

然后，当鼠标指针碰到图标时，一个小的弹出窗口会收集所有图标变体以供查看（以较小的图标尺寸或更大的图标尺寸）。当您将鼠标悬停在上方时，每个覆盖的图标都会通过工具提示宣布其含义。

现在，您可以拥有所需的所有图标叠加层，各种云中的状态，存储库指示以及Tortoise工具等等。