ICO文件格式的演化（三）：带透明通道的图标
原文：http://blogs.msdn.com/b/oldnewthing/archive/2010/10/21/10078690.aspx
Windows XP引入了带8位透明通道的图标。而在这之前，只有一个称为mask的1位透明通道。
在ICO文件中带透明通道的图像很简单。既然ICO格式支持0RGB 32bpp的图像，那么为了支持透明通道，只要改成ARGB 32bpp就可以了。当窗口管理器看到一个32bpp的图标，它会检查一遍透明通道。如果都是零，则认为是0RGB格式，否则就认为是ARGB格式。而文件的其它部分和以前一样。
要注意文件的其它部分和以前一样。也就是，你仍然要提供mask。我看到有些人懒得提供一个有意义的mask，而把它都填零。这样，除了一些特殊情况会出现问题，一般都能正常工作。
基本上有三种绘制带透明通道的图标。
- DrawIcon(DI_NORMAL)：最一般的调用。对于有透明通道的情况下，则将image和目的图像alpha混合。
- DrawIcon(DI_IMAGE)：将图标中image部分覆盖到目的上。
- DrawIcon(DI_MASK)：只绘制图标中的mask副本，并覆盖的目的上。
DI_IMAGE和DI_MASK选项让应用程序能够绘制图标中两个图像中的其中一个。这样应用程序可以更好的控制图标的绘制流程。例如：他们可以通过mask给图标加一个阴影。mask表示图标的那部分是不透明的，需要产生阴影。
至此，你应该了解到那些把mask都填零的人为什么在大多数情况下都是幸运的。因为大多数程序使用DI_NORMAL绘制图标。那个错误的mask从来不被使用，错误从没被发现。直到某个程序想对图标作一些特殊效果，并使用了DI_MASK（或者调用GetIconInfo，得到其中的hbmMask），然后那个错误mask才导致图标很难到。
讽刺的是，那些错误地把mask填零的人总是反过来说“用透明通道的图标，在情况X和Y下，结果很难看。ms的程序员都是sb。这更说明了Widows是一堆bug组成的。”他们没有意识到，难看的结果是由他们的错误所造成的。
