ICL.TXT - Description of the .ICL icon library graphics format. E-Mail: shawkie@geocities.com Visit: http://www.geocities.com/SiliconValley/Vista/2471/ 08/06/97 10/06/97 ______________________________________________________________________ For a much more readable summary, see "The scary world of the .ICL Icon Library", at the end of this file. This part is intended to show how I came to my conclusions. ______________________________________________________________________ Results from investigating .ICL files containing 1, 2 ,3 and 4 icons. (No useful conclusions as yet) Note: These .ICL files were formed from a single original and some of their similarities are due to that. ______________________________________________________________________ DOES ANYONE HAVE THE FORMAL SPECIFICATIONS FOR A .ICL FILE??????? ______________________________________________________________________ All offsets are probably broken (tanx to MS DEBUG). Take 0100h from each to get true offsets. (If I did this everything would probably make sense too :-) 01C4: 01 00 1 icon 02 00 2 icons 03 00 3 icons 04 00 4 icons Well, at least I know how many icons in each library! :-) I'm sure this is some kind of index. But I don't really understand it. 30 1C ?? 80 00 00 00 00 ?? ?? ?? ?? Icon No Some kind of offset?/SIZE?? 01CE: 01 03 80 01 00 One per ICO file!!! 01E2: 01 00 00 03 49 One per image!!! (Execpt the last one gets scrubbed by the 'ICL' ??? ) 01EC: 'ICL' 01F6: Icon Image Data 01CE: 01 93 00 0A 00 01DA: 02 03 80 02 00 ^^^^^ No of images TOTAL in library (hence no. of lines to follow for images!! Ah! ) 01EE: 01 F1 04 54 04 01FA: 02 'ICL' already started!! 0204: 'ICL' 01CE: 01 A1 00 0A 00 01DA: 02 AB 00 0A 00 01E6: 03 03 80 03 00 01FA: 01 09 05 54 04 0206: 02 5D 09 54 04 0212: 03 00 00 03 49 021C: 'ICL' 01CE: 01 AF 00 0A 00 01DA: 02 B9 00 0A 00 01E6: 03 C3 00 0A 00 01F2: 04 03 80 04 00 0206: 01 21 05 54 04 0212: 02 75 09 54 04 021E: 03 C9 0D 54 04 022A: 04 00 00 03 49 0234: 'ICL' For the 256th icon, the 80 in the 'common part' becomes an 81 and the Icon No's start from 01 again Names are stored in form: B Length of name (bytes) B[] Name eg. 04 37 31 30 30 means the 4 letters: '7','1','0','0' Preceding the icon names is another string, usually 'ICL' in same format. ie. 03 49 4C 43 meaning the 3 letters: 'I','C','L' This preceding string starts 0Ah bytes from the start of the last index-item/thing/whatever. _ | | / \ | | | I should now be able to write a program which tells | | | | | | | you how many icons there are in any particular .ICL |/\| \_/ |/\| . file, and their names! Excellent! _______________________________________________________________________ This library is a cut down from a different original to the previous 4. However, it still has many similarities. 01CE: 01 60 00 05 00 01DA: 02 65 00 05 00 01E6: 03 6A 00 05 00 01F2: 04 03 80 04 00 0206: 01 99 02 2A 02 0212: 02 C3 04 2A 02 021E: 03 ED 06 2A 02 022A: 04 00 00 03 49 0234: 'ICL' 00A6: B4 4icons! 9C 3icons! 84 2icons! 00CA: A5 4 97 3 89 2 00D6: AF 4 A1 3 There is a **complete** ICONDIR for each .ICO file. Except, the dwImageOffset is replaced by the no. of the image in the .ICL file. (WORD not DWORD) So far found no way to locate offset of table or image data. In one case, table, was 2 bytes: 00 00 from end of name table 1 byte : 00 " 016C 014A 012E 0112 00F6 00CA: 016C 4object.icl (gap of 1 byte) 6C 01 14 00 x1 013F 2object2.icl (gap of 1 byte) 3F 01 22 00 x1 0159 1object2.icl (gap of 1 byte) 59 01 30 00 x1 00F6 1object.icl (gap of 2 bytes) 7B 00 0A 00 x2 0112 2object.icl (gap of 1 byte) 89 00 0A 00 x2 012E 3object.icl (gap of 1 byte) 97 00 0A 00 x2 014A 4object2.icl (gap of 2 bytes) A5 00 0A 00 x2 01DF sci-fi.icl DF 01 14 00 x1 8 icons 0341 toilets.icl 41 02 14 00 x1 11 icons 03A9 weird1~1.icl A9 03 14 00 x1 17 icons 026A icons.icl 6A 02 22 00 x1 10 icons 02E0 eyes.icl 70 01 0A 00 x2 17 icons 060C anime.icl 06 03 0A 00 x2 49 icons 0A0A people.icl 05 05 0A 00 x2 76 icons 0A44 bebox.icl 91 02 05 00 x4 69 icons 0A14 startr~1.icl 85 02 05 00 x4 70 icons 07D8 xfiles.icl F6 01 09 00 x4 44 icons 2F48 misc.icl E9 05 03 00 x8 370 icons 12F8 3d.icl 5F 02 05 00 x8 88 icons 2748 misc2.icl E9 04 03 00 x8 306 icons 00A6: F0 06 F8 0D 40 23 34 1D I have a theory that in any particular file the multiplier is the same for every offset!! ========================================================================================== __________________________________________________________________________________________ The scary world of the _____ _____ ___ |_ _| / _ \ | | E-mail: shawkie@geocities.com | | ( / \__) | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __ | | _ _| |_ ( \_/ ) _| |____| | * |___| \_____/ |_________| Icon Library. __________________________________________________________________________________________ Ok, so I'm not ascii-artistic. :) __________________________________________________________________________________________ ========================================================================================== Here starts my formal description of the .ICL icon library. I have had access to no formal information from any source, so this may all be completely wrong. There is certainly NOT enough information here to allow you to write your own ICL libraries, the aim however is to enable you to write programs which can READ them. I hope there is enough here to make that possible - after all, that is what I am trying to do! I have basically refined the information above. Some it was incorrect, some poorly expressed. I have also added a little new information. To me this file format appears to be EXTREMELY BIZZARE! This is a sure sign of me having got something wrong! I hope this is understandable - if someone modifies/corrects it, would they please e-mail me with it. __________________________________________________________________________________________ 00C4 W No of Icons Following immediately, one of these structures for each icon: { W 0000h W 0000h DW 'Strange' offset of resolution info, etc. (see "Offsets?????") (This information is a table containing details for all images in that icon.) B 30h B 1Ch B IconNo B 80h + high part of IconNo } 6 BYTES W No of Images Following immediately, one of these structures for each image: { W 0000h W 0000h DW 'Strange' offset of actual image data (see "Offsets?????") B 30h B 1Ch B ImageNo B 80h + high part of ImageNo } 6 BYTES B No of characters in LibraryName B[] LibraryName usually "ICL" Following immediately, one of these structures for each icon: { B No of characters in IconName B[] IconName } ============ Offsets????? ============ Offsets in .ICL files are stored in a **VERY WEIRD** way. They are DWs, eg. 3F 01 22 00 BUT, they are not actual 'offsets'. They are in fact 2 WORDS. eg 013Fh and 0022h from above example. The offset itself - the position of whatever in the file - is a 1x, 2x, 4x, 8x, etc. multiple of the first WORD. In the above case it would probably be 1x so the offset is 013Fh. The second WORD may help determine what to multiply the first WORD by, I don't really know. ;-) As I said before, I have a theory that for any particular file, the multiplier is the same for every offset. (This is a *THEORY* ;-) ===================== Resolution Info, etc. ===================== For each Icon in the .ICL file there is a header, almost identical to that found in a normal .ICO file. It tells you how many Images in the Icon, and details the dimensions, colour depths, etc. for each. In a normal .ICO header file, there is also a DW containing the offset of the image data. In the .ICL file this is replaced by the index of the image (a WORD). This is the format of the header found in a standard .ICO file. (It is pasted from another source, so slightly differently formated) typedef struct { WORD idReserved; // Reserved (must be 0) WORD idType; // Resource Type (1 for icons) WORD idCount; // How many images? ICONDIRENTRY idEntries[1]; // An entry for each image (idCount of 'em) } ICONDIR, *LPICONDIR; The idCount member indicates how many images are present in the icon resource. The size of the idEntries array is determined by idCount. There exists one ICONDIRENTRY for each icon image in the file, providing details about its location in the file, size and color depth. The ICONDIRENTRY structure is defined as: typedef struct { BYTE bWidth; // Width, in pixels, of the image BYTE bHeight; // Height, in pixels, of the image BYTE bColorCount; // Number of colors in image (0 if >=8bpp) BYTE bReserved; // Reserved ( must be 0) WORD wPlanes; // Color Planes WORD wBitCount; // Bits per pixel DWORD dwBytesInRes; // How many bytes in this resource? DWORD dwImageOffset; // Where in the file is this image? } ICONDIRENTRY, *LPICONDIRENTRY; To apply this to an Icon header from a .ICL file, simply change: DWORD dwImageOffset; // Where in the file is this image? To: WORD wImageIndex; // Which image in the library is this? ========== Image Data ========== This is stored in EXACTLY the same way as in a .ICO file: For each ICONDIRENTRY, the file contains an icon image. The dwBytesInRes member indicates the size of the image data. This image data can be found dwImageOffset bytes from the beginning of the file, and is stored in the following format: typdef struct { BITMAPINFOHEADER icHeader; // DIB header RGBQUAD icColors[1]; // Color table BYTE icXOR[1]; // DIB bits for XOR mask BYTE icAND[1]; // DIB bits for AND mask } ICONIMAGE, *LPICONIMAGE; __________________________________________________________________________________________ Further Information: At the moment I have no more information on .ICL files specifically, but I know enough about .ICO to be able to read them in a reliable way - so if you need more help there, let me know. I will release new versions of this file if I discover errors or improvements which I could make. I also intend to write a C program which will read .ICL files ( to convert them to .XPM files for X Windows - That format is a 'good thing' ) I have already written a program which does this for .ICO files. My .ICO viewer compiles under MS QuickC 2.5 My .ICO to .XPM converter compiles under MS QuickC and GNU C++ (The version for GNU C++ under linux is slightly simpler because it does not have to be concerned about the broken 8.3 character filename restriction :-) I also now have a viewer for .ICL libraries (It's a little quick and dirty at the moment, and is limited to 256 icons per file, 16 images per icon, and a total of 2048 images. ==============================================EOF=========================================