[File] [PATCH] of Magdir/images, msdos for OS/2 graphic array (*.bmp *.ico)

Christos Zoulas christos at zoulas.com
Mon Jun 24 23:56:40 UTC 2019


Committed, thanks!

christos

> On Jun 23, 2019, at 8:12 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> some days ago i handle some OS/2  graphic array with file name
> extension "ico" or "bmp". When i run file command version 5.37 many
> of these examples are only described as "data" and some are
> misidentified as "Icon for MS Windows" like
> 
> BOOKOS2.ICO:     Icon for MS Windows
> SPADE.BMP:       data
> Util. 03.ICO:    Icon for MS Windows
> 
> So i add/change lines in Magdir/images. Some Information is found on
> fileformats.archiveteam.org website. So i add comment line like
> # URL: http://fileformats.archiveteam.org/wiki/BMP#OS.2F2_Bitmap_Array
> 
> In Magdir/image there exist an attempt to identify such examples by
> line
> #0	string		BA		PC bitmap array data
> 
> This pattern is too simple. So this line now becomes
> 0	string		BA
> 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 array i found low values like 28h 5Ch.
> 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.
> 
> So i skip old Emacs RMAIL starting with phrase "BABYL OPTIONS:" by
> checking for low header size:
>> 2	ulelong		<0x004c5942	OS/2 graphic array
> 
> The dimensions of the device for which this version is intended is
> stored in variables cxDisplay, CyDisplay. If not null show this
> display dimensions (640 x 480 for example means VGA) by lines
>>> 10	uleshort	>0		\b, display %u
>>>> 12	uleshort	>0		x %u
> 
> After the first header comes the first element of the graphic array.
> The type of that element can be inspected by a debug line like
>>> 14	string		x		\b, usType %2.2s
> So it is visible that inspected array examples are just container
> for OS/2 icon "IC", color icon "CI", color pointer "CP" or bitmap
> "BM". Depending on embedded elements the files name extension is
> different. For bitmaps the extension is "bmp" and "ico" for other
> cases. This is expressed by lines
>>> 14	string		BM	\b; 1st
> !:ext	bmp/bga
>>> 14	string		CI	\b; 1st
> !:ext	ico
>>> 14	string		CP	\b; 1st
> !:ext	ico
>>> 14	string		IC	\b; 1st
> !:ext	ico
> According to documentation also "bga" extension is possible, but i
> found no example for that case. I also found no array with
> white-black OS/2 pointers "PT".
> For the OS/2 bitmaps, icons, pointer there exist already magic test
> lines. So i use existing lines and inspect first array element by line
>>> 14	indirect	x
> 
> Some OS/2 graphic array are misidentified by line in Magdir/msdos
> which looks like:
> 0 string/b \102\101\050\000\000\000\056...	Icon for MS Windows
> With the knowledge of the documentation we can interpret the octal
> values. So \102\101 as ASCII is BA for OS/2 graphic array. cbSize
> value 40 is equivalent of \050\000\000\000. data offset 46 is same as
> \056\000\000\000 and the remaining null means display dimension 0x0.
> So what is expressed by line in Magdir/msdos is not a Windows icon,
> but an OS/2 graphic array with specif values for cbSize, data offset
> and display dimensions. So i remove that misidentifying lines by
> file-5.37-msdos-ico.diff.
> 
> After applying the above mentioned modifications also by patch
> file-5.37-images-bmp_ico.diff then unrecognized OS/2 graphic array
> are now recognized and together with former patches for OS/2
> graphics described like
> 
> BOOKOS2.ICO:     OS/2 graphic array, cbSize 40, data offset 46;
> 	1st OS/2 icon, cbSize 26, hotspot 8x8,
> 	bits offset 618
> CDPlyr-1.ICO:    OS/2 graphic array, cbSize 92, data offset 230;
> 	1st OS/2 2.x color icon 32 x 32, hotspot 16x16, cbSize 78,
> 	bits offset 1018
> Flag-Canada.ICO: OS/2 graphic array, cbSize 92, data offset 242;
> 	1st OS/2 2.x color icon 64 x 64, hotspot 7x52, cbSize 78,
> 	bits offset 1098
> Folder-C.ICO:    OS/2 graphic array, cbSize 40, data offset 78;
> 	1st OS/2 1.x color icon 16 x 16, hotspot 8x8, cbSize 26,
> 	bits offset 636
> LiveWire2.ICO:   OS/2 graphic array, cbSize 92;
> 	1st OS/2 2.x color pointer 32 x 32, hotspot 21x20, cbSize 78,
> 	bits offset 242
> MEMSIZE.BMP:     OS/2 graphic array, cbSize 40;
> 	1st PC bitmap, OS/2 1.x format, 64 x 64
> MIDIFil1.ICO:    OS/2 graphic array, cbSize 92, data offset 198;
> 	1st OS/2 2.x color icon 32 x 32, hotspot 16x16, cbSize 78,
> 	bits offset 958
> MIDIPly1.ICO:    OS/2 graphic array, cbSize 92, data offset 218;
> 	1st OS/2 2.x color icon 32 x 32, hotspot 16x16, cbSize 78,
> 	bits offset 990
> OS2SysF.ICO:     OS/2 graphic array, cbSize 92, data offset 100;
> 	1st OS/2 icon, cbSize 78, hotspot 8x8,
> 	bits offset 2470
> RMAIL:           Emacs RMAIL
> screwdri.ico:    OS/2 graphic array, cbSize 92,
> 	display 1024 x 768;
> 	1st OS/2 2.x color icon 40 x 40, hotspot 20x20, cbSize 78,
> 	bits offset 242
> SndPly-1.ICO:    OS/2 graphic array, cbSize 92, data offset 210;
> 	1st OS/2 2.x color icon 32 x 32, hotspot 16x16, cbSize 78,
> 	bits offset 978
> SndRec-2.ICO:    OS/2 graphic array, cbSize 92, data offset 214;
> 	1st OS/2 2.x color icon 32 x 32, hotspot 16x16, cbSize 78,
> 	bits offset 978
> SPADE.BMP:       OS/2 graphic array, cbSize 92;
> 	1st PC bitmap, OS/2 2.x format, 58 x 0
> Util. 03.ICO:    OS/2 graphic array, cbSize 40, data offset 46;
> 	1st OS/2 icon, cbSize 26, hotspot 8x8,
> 	bits offset 332
> VdscPly1.ICO:    OS/2 graphic array, cbSize 92, data offset 234;
> 	1st OS/2 2.x color icon 32 x 32, hotspot 16x16, cbSize 78,
> 	bits offset 1018
> VxFTP.ICO:       OS/2 graphic array, cbSize 40, data offset 840,
> 	display 640 x 350;
> 	1st OS/2 1.x color icon 40 x 40, hotspot 0x0, cbSize 26,
> 	bits offset 1080
> 
> I hope my diff files can be applied in future version of file utility.
> 
> There still exist more bitmap variants which are not recognized or
> misidentified by file command. I will handle such things in a future
> session.
> 
> With best wishes
> Jörg Jenderek
> - --
> Jörg Jenderek
> 
> 
> 
> 
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCXRAVZAAKCRCv8rHJQhrU
> 1tlJAKChUOyzk1i4nsJvEMlQOnfVbNnj8wCfRO7qf1Z9/HE7rdMBP4ERb1wuRSs=
> =kG3l
> -----END PGP SIGNATURE-----
> <file-5_37-msdos-ico_diff.DEFANGED-2><file-5_37-images-bmp_ico_diff.DEFANGED-3><file-5_37-msdos-ico_diff_sig.DEFANGED-4><file-5_37-images-bmp_ico_diff_sig.DEFANGED-5>-- 
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>



More information about the File mailing list