{"id":7083,"date":"2012-07-20T07:00:00","date_gmt":"2012-07-20T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2012\/07\/20\/the-format-of-icon-resources\/"},"modified":"2012-07-20T07:00:00","modified_gmt":"2012-07-20T07:00:00","slug":"the-format-of-icon-resources","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20120720-00\/?p=7083","title":{"rendered":"The format of icon resources"},"content":{"rendered":"

\nIt’s been a long time since my last entry in the continuing\nsporadic series on resources formats.\nToday we’ll look at icons.\n<\/p>\n

\nRecall that an icon file\n\nconsists of two parts<\/a>,\nan icon directory<\/i>\n(consisting of an icon directory header followed by a number of\nicon directory entries),\nand then the icon images themselves.\n<\/p>\n

\nWhen an icon is stored in resources, each of those parts gets its own\nresource entry.\n<\/p>\n

\nThe icon directory (the header plus the directory entries)\nis stored as a resource of type\nRT_GROUP_ICON<\/code>.\nThe format of the icon directory in resources is slightly different\nfrom the format on disk:\n<\/p>\n

\ntypedef struct GRPICONDIR\n{\n    WORD idReserved;\n    WORD idType;\n    WORD idCount;\n    GRPICONDIRENTRY idEntries[];\n} GRPICONDIR;\ntypedef struct GRPICONDIRENTRY\n{\n    BYTE  bWidth;\n    BYTE  bHeight;\n    BYTE  bColorCount;\n    BYTE  bReserved;\n    WORD  wPlanes;\n    WORD  wBitCount;\n    DWORD dwBytesInRes;\n    WORD  nId;\n} GRPICONDIRENTRY;\n<\/pre>\n
\nAll the members mean the same thing as in the corresponding\nICONDIR<\/code> and IconDirectoryEntry<\/code>\nstructures, except for that mysterious nId<\/code>\n(which replaces the dwImageOffset<\/code> from the\nIconDirectoryEntry<\/code>).\nTo unravel that mystery, we need to look at where\nthe rest of the icon file went.\n<\/p>\n
\nIn the icon file format,\nthe dwImageOffset<\/code> represented the location\nof the icon bitmap within the file.\nWhen the icon file is converted to a resource,\neach icon bitmap is split off into its own resource\nof type RT_ICON<\/code>.\nThe resource compiler auto-assigns the resource IDs,\nand it is those resource IDs that are stored in the\nnId<\/code> member.\n<\/p>\n
\nFor example, suppose you have an icon file with four\nimages.\nIn your resource file you say\n<\/p>\n
\n42 ICON myicon.ico\n<\/pre>\n
\nThe resource compiler breaks the file into five resources:\n<\/p>\n\n\n\n\n\n\n\n
Resource type<\/th>\nResource Id<\/th>\nContents<\/th>\n<\/tr>\n
RT_GROUP_ICON<\/code><\/td>\n42<\/td>\nGRPICONDIR.idCount = 4<\/code>
\n        GRPICONDIRENTRY[0].nId = 124<\/code>
\n        GRPICONDIRENTRY[1].nId = 125<\/code>
\n        GRPICONDIRENTRY[2].nId = 126<\/code>
\n        GRPICONDIRENTRY[3].nId = 127<\/code>\n    <\/td>\n<\/tr>\n
RT_ICON<\/code><\/td>\n124<\/td>\nPixels for image 0<\/td>\n<\/tr>\n
RT_ICON<\/code><\/td>\n125<\/td>\nPixels for image 1<\/td>\n<\/tr>\n
RT_ICON<\/code><\/td>\n126<\/td>\nPixels for image 2<\/td>\n<\/tr>\n
RT_ICON<\/code><\/td>\n127<\/td>\nPixels for image 3<\/td>\n<\/tr>\n<\/table>\n
\nWhy does Windows break the resources into five pieces instead of just\ndumping them all inside one giant resource?\n<\/p>\n
\nRecall\n\nhow 16-bit Windows managed resources<\/a>.\nBack in 16-bit Windows, a resource was a handle into a table,\nand obtaining the bits of the resource involved allocating memory and\nloading it from the disk.\nRecall also that 16-bit Windows operated under tight memory constraints,\nso you didn’t want to load anything into memory unless you really\nneeded it.\n<\/p>\n
\nTherefore, looking up an icon in 16-bit Windows went like this:\n<\/p>\n