[File] [PATCH] of Magdir/images for OS/2 "CI" color icon variant (*.ico)

[Christos Zoulas]

On Jun 19,  3:49pm, joerg.jen.der.ek at gmx.net (=?UTF-8?Q?J=c3=b6rg_Jenderek?=) wrote:
-- Subject: [File] [PATCH] of Magdir/images for OS/2 "CI" color icon variant 

| Hello,
| some days ago i handle some OS/2 color icons with file name extension
| "ico". When i run file command version 5.37 all of these examples
| are only described as "data".
| 
| More irritating is the fact that ico extension is used for MS
| Windows icons. Many popular graphic tools like GIMP, ImageMagick or
| XnView can open the Microsoft icon variant, but are not able to open
| that OS/2 icon variant. Finally i find a command line converter tool
| "deark" which is able to handle such icons by module os2bmp. So
| information about inspected icon is shown by list and debug option
| like in example command line:
| 	deark -l -d3 os220.ico
| 
| So i add/change lines in Magdir/images. Some Information is found on
| fileformats.archiveteam.org website.
| In Magdir/image there exist an attempt to identify such examples by
| line
|  #0	string		CI		PC color icon data
| 
| Maybe this pattern is too simple. So this line now becomes
|  0	string		CI
| And more additional test lines are needed to skip bad examples.
| 
| The size of header or file in bytes is stored in variable cbSize.
| This is now shown by line like
|  >>2	ulelong			x	\b, cbSize %u
| For inspected OS/2 color icons i found low values like 1Ah 4Eh 84Eh.
| This can be used as additional test by jumping 4 bytes before end of
| header/file and test for accessibility by line like
|  >>(2.l-4) ubelong		x	End of header is OK!
| I do not use this, because accessing bytes beyond ranges is not a
| official documented feature in file command.
| 
| The coordinates of the hotspot for icons like 0 1 16 20 32 33 63 64
| are stored in 2 bytes variables xHotspot and yHotspot, which are now
| shown by lines like
|  >>6	uleshort		x	\b, hotspot %ux
|  >>8	uleshort		x	\b%u
| 
| Nowadays icon can becomes big with dimensions, but in ancient times of
| OS/2 systems with less RAM dimensions are low. The typical dimension
| sizes are 32 40 64. But i also found higher dimensions 128 and 256
| like in "DOOM!2 01.ICO". That also means in real examples hot spot
| values are low (maybe maximal 256). So upper bits of short stored
| value seems to be always null. So maybe skip bad examples by looking
| for valid hot spot coordinates by additional test line like
|  >>6	ulelong&0xFE00FE00	=3D0
| But i do not use this test.
| 
| After the first header comes the DIB header. In the first 4 bytes the
| DIB header size is stored. This can be shown by line like
|  >>14	ulelong		x		\b, dib header size %u
| For the considered color icons only 2 values 12 or 64 occur. So test
| also for valid dib header sizes and start displaying by line
|  >14	ulelong		<65		OS/2
| Now afterwards show file name extension and a user defined mime type
| by lines
|  !:mime	image/x-os2-ico
|  !:ext	ico
| 
| Afterwards split into 2 branches parts. First considered the OS/2 1.x
| variant by checking for dib header size twelve and show specific icon
| dimensions by lines
|  >>14	ulelong		12		1.x color icon
|  >>>18	uleshort	x		%u x
|  >>>20	uleshort/2	x		%u
|  >>>24	uleshort	>1		x %u
| 
| For OS/2 image width and height fields are unsigned integers whereas
| for Microsoft Windows variants signed integers are used. The stored
| height value was always the double of the real height. I found no
| explanation about this item. So dived value by 2 before displaying
| value. Typical values for number of bits per pixel (color depth) are
| 32 24 16 8 4 1, but i only found value one. So show this values only
| if  not one.
| 
| The other branch is for the OS/2 2.x variant which start with looking
| for dib header size 64 and then display specific dimension by lines
|  >>14	ulelong		64		2.x color icon
|  >>>18	ulelong		x		%u x
|  >>>22	ulelong/2	x		%u
|  >>>28	uleshort	>1		x %u
| The main difference is that width and height values are stored as 4
| byte values instead by 2 bytes.
| 
| After applying the above mentioned modifications by patch
| file-5.37-images-ico-CI.diff then unrecognized OS/2 color icons are
| now recognized and described like
| 
| 4DOS-B.ICO:     OS/2 1.x color icon 32 x 32,
| 	hotspot 1x31, cbSize 26, bits offset 106
| Car 02.ICO:     OS/2 1.x color icon 80 x 80,
| 	hotspot 0x0, cbSize 26, bits offset 826
| DOOM!2 01.ICO:  OS/2 2.x color icon 128 x 128,
| 	hotspot 64x64, cbSize 78, bits offset 1188
| os22-16rle.ico: OS/2 2.x color icon 256 x 256,
| 	Huffman 1D compression,
| 	hotspot 128x128, cbSize 78, bits offset 228
| os220.ico:      OS/2 2.x color icon 40 x 40,
| 	hotspot 20x20, cbSize 78, bits offset 228
| Team_OS2.ICO:   OS/2 1.x color icon 64 x 64,
| 	hotspot 32x32, cbSize 26, bits offset 106
| The_Ray.ICO:    OS/2 1.x color icon 64 x 64,
| 	hotspot 33x63, cbSize 26, bits offset 826
| toolsfop.ico:   OS/2 1.x color icon 32 x 32,
| 	hotspot 16x16, cbSize 26, bits offset 58
| 
| I hope my diff file can be applied in future version of file utility.
| 
| There still exist more OS/2 icons and bitmap files which are not
| recognized or misidentified by file command. I will handles such
| things in future session.

Applied, thanks! I still think that the magic is a bit weak, but I guess
improvements would make the magic a lot more complicated (to check dimension
sanity before printing for example).

christos