[File] [PATCH] of Magdir/images for OS/2 color pointer "CP" variant (*.ptr)

Mon Jun 24 23:50:33 UTC 2019

Added, thanks!

christos

> On Jun 21, 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 color pointer with file name
> extension "ptr". When i run file command version 5.37 all of these
> examples are only described as "data".
> 
> 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/OS/2_Pointer
> 
> In Magdir/image there exist an attempt to identify such examples by
> line
> #0	string		CP		PC color pointer image data
> 
> This pattern is too simple. So this line now becomes
> 0	string		CP
> And more additional test lines are needed to skip bad examples like
> CPU-Z Reports.
> 
> 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 pointers i found low values like 1Ah 4Eh
> 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 hot spot for icons like 0 3 4 8 15 16 23 27 31
> 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. 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	=0
> 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 pointers 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
> according to nirsoft.net extension web site by lines
> !:mime	image/x-ibm-pointer
> !:ext	ptr
> 
> 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. 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-ptr-CP.diff then unrecognized OS/2 color pointers
> are now recognized and described like
> 
> cpuz.txt:      ISO-8859 text, with CRLF line terminators
> 128-256.ptr:   OS/2 2.x color pointer 128 x 128,
> 	hotspot 64x64, cbSize 78, bits offset 1188
> 256-24rle.ptr: OS/2 2.x color pointer 256 x 256,
> 	Huffman 1D compression,
> 	hotspot 128x128, cbSize 78, bits offset 164
> MOVE.PTR:      OS/2 1.x color pointer 32 x 32,
> 	hotspot 10x21, cbSize 26, bits offset 106
> os22-64.ptr:   OS/2 2.x color pointer 32 x 32,
> 	hotspot 16x16, cbSize 78, bits offset 164
> sizens.PTR:    OS/2 1.x color pointer 32 x 32,
> 	hotspot 15x31, cbSize 26, bits offset 106
> SIZENWSE.PTR:  OS/2 1.x color pointer 32 x 32,
> 	hotspot 3x27, cbSize 26, bits offset 106
> WAITHOUR.PTR:  OS/2 1.x color pointer 32 x 32,
> 	hotspot 15x16, cbSize 26, bits offset 106
> 
> 
> I hope my diff file can be applied in future version of file utility.
> 
> There still exist more OS/2 pointer and array files which are not
> recognized or misidentified by file command. I will handles such
> things in 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+v8rHJQhrU1gUCXQ1yQgAKCRCv8rHJQhrU
> 1hRoAJ9Y458MaEMVNE5dzlCE/Rge/xUQQQCgoMZIVUpQhhsnO8iwK4JwcLxd+AU=
> =NiMD
> -----END PGP SIGNATURE-----
> <file-5_37-images-ptr-CP_diff.DEFANGED-8><file-5_37-images-ptr-CP_diff_sig.DEFANGED-9>-- 
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>