\nThis week is devoted to the evolution of the ICO file format.\nNote that the icon resource format is different from the ICO file format;\nI’ll save that topic for another day.\n<\/p>\n
\nThe ICO file begins with a fixed header:\n<\/p>\n
\ntypedef struct ICONDIR {\n WORD idReserved;\n WORD idType;\n WORD idCount;\n ICONDIRENTRY idEntries[];\n} ICONHEADER;\n<\/pre>\n\nidReserved<\/code> must be zero, and idType<\/code> must be 1.\nThe idCount<\/code> describes how many images are included in this\nICO file.\nAn ICO file is really a collection of images;\nthe theory is that each image is an alternate representation of the same\nunderlying concept, but at different sizes and color depths.\nThere is nothing to prevent you, in principle, from creating an ICO file\nwhere the 16×16 image looks nothing like the 32×32 image,\nbut your users will probably be confused.\n<\/p>\n\nAfter the idCount<\/code> is an array of ICONDIRECTORY<\/code>\nentries whose length is given by idCount<\/code>.\n<\/p>\n\nstruct IconDirectoryEntry {\n BYTE bWidth;\n BYTE bHeight;\n BYTE bColorCount;\n BYTE bReserved;\n WORD wPlanes;\n WORD wBitCount;\n DWORD dwBytesInRes;\n DWORD dwImageOffset;\n};\n<\/pre>\n\nThe bWidth<\/code> and bHeight<\/code> are the dimensions of\nthe image.\nOriginally, the supported range was 1 through 255,\nbut starting in Windows 95 (and Windows NT 4),\nthe value 0 is accepted as representing a width or height of 256.\n<\/p>\n\nThe wBitCount<\/code> and\nwPlanes<\/a><\/code>\ndescribe the color depth of the image;\nfor monochrome icons, these value are both 1.\nThe bReserved<\/code> must be zero.\nThe dwImageOffset<\/code> and dwBytesInRes<\/code>\ndescribe the location (relative to the start of the ICO file)\nand size in bytes of the actual image data.\n<\/p>\n\nAnd then there’s bColorCount<\/code>.\nPoor bColorCount<\/code>.\nIt’s supposed to be equal to the number of colors in the image;\nin other words,\n<\/p>\n\nbColorCount = 1 << (wBitCount * wPlanes)<\/code>\n<\/p>\nIf wBitCount * wPlanes<\/code> is greater than or equal to 8,\nthen bColorCount<\/code> is zero.<\/p>\n\nIn practice, a lot of people get lazy about filling in the\nbColorCount<\/code> and set it to zero,\neven for 4-color or 16-color icons.\nStarting in Windows XP,\nWindows autodetects this common error,\nbut its autocorrection is slightly buggy in the case of planar bitmaps.\nFortunately, almost nobody uses planar bitmaps any more,\nbut still, it would be in your best interest not to rely on the\nautocorrection performed by Windows and just set your bColorCount<\/code>\ncorrectly in the first place.\nAn incorrect bColorCount<\/code> means that when Windows tries to\nfind the best image for your icon, it may choose a suboptimal one\nbecause it based its decision on incorrect color depth information.\n<\/p>\n\nAlthough it probably isn’t true,\nI will pretend that monochrome icons existed before color icons,\nbecause it makes the storytelling easier.\n<\/p>\n
\nA monochome icon is described by two bitmaps, called AND<\/i>\n(or mask<\/i>)\nand XOR<\/i> (or image<\/i>, or when we get to color icons, color<\/i>).\nDrawing an icon takes place in two steps:\nFirst, the mask is ANDed with the screen, then the image is XORed.\nIn other words,\n<\/p>\n
\npixel = (screen AND mask) XOR image<\/code>\n<\/p>\n\nBy choosing appropriate values for mask<\/i> and image<\/i>,\nyou can cover all the possible monochrome BLT operations.\n<\/p>\n