[File] [PATCH] of Magdir/images for OS/2 "CI" color icon variant (*.ico)
christos at zoulas.com
Wed Jun 19 15:25:50 UTC 2019
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
| 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
| #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).
More information about the File