[File] [PATCH] of Magdir/msvc, database, sysex for Microsoft Visual C or OMF library *.LIB

Christos Zoulas christos at zoulas.com
Mon Jan 17 17:19:24 UTC 2022


Wow, applied thanks!

christos

> On Jan 15, 2022, at 8:34 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> some days ago i handled some libraries with file name extension LIB.
> 
> When running file command version 5.41 on some examples
> and related files with --keep-going option i get an output like:
> 
> DBFNTX.LIB:             SysEx File - Inventronics
> FLIB7M.LIB:             data
> FP87.LIB:               Microsoft Visual C library
> 			SysEx File - ADA
> JMPPM32.LIB:            Microsoft Visual C library
> 			SysEx File - ADA
> MOUSE.LIB:              data
> PRESET_6.SYX:           SysEx File -
> QB4UTIL.LIB:            Microsoft Visual C library
> 			SysEx File - ADA
> T2.DBT:                 dBase III DBT,
> 			next free block index 11,
> 			1st item "First memo\032\032"
> WATTCPWL.LIB:           dBase III DBT, version number 0,
> 			next free block index 130544,
> 			1st item "\200 "
> ZLIB.LIB:               dBase III DBT, version number 0,
> 			next free block index 130544,
> 			1st item "\200M"
> example-1manband.syx:   SysEx File -
> example-apple.syx:      SysEx File - Apple
> example-somascape2.syx: SysEx File -
> example-webmidijs.syx:  SysEx File -
> example-yamaha.syx:     SysEx File - Yamaha
> mlibce.lib:             Microsoft Visual C library
> 			SysEx File - ADA
> mwlibc.lib:             Microsoft Visual C library
> 			SysEx File - ADA
> 
> With --extension option wrong 3 byte extension "dbt" or ??? are
> displayed and with -i option wrong mime type application/x-dbt or
> only generic application/octet-stream is shown.
> 
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). This describes one
> SysEx example PRESET_6.SYX as "MIDI Emulator Project SysEx preset
> command" by syx--midiemu.trid.xml whereas the file command display no
> vendor name for this type (66h).
> 
> The libraries recognised by file command are also described as
> "Microsoft Visual C Library" by lib-msvc.trid.xml, but TrID also
> describe some examples like DBFNTX.LIB correctly.
> (See appended lib_syx-trid-v.txt.gz)
> 
> Luckily TrID tool displays correct file name extension LIB for
> inspected libraries and SYX for few SysEx files.
> This list with -v option the related URL pointing to used file
> information.
> 
> The information of TrID points to page about Microsoft Visual C++
> on Wikipedia. This was not so helpful, but on file formats archive
> team website i found a page about Microsoft Library (*.lib). From
> there i get the right hint that the used file format is the
> Relocatable Object Module Format (OMF). So that information is now
> expressed inside Magdir/msvc by comment lines like:
> # URL: 	https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B
> #	http://fileformats.archiveteam.org/wiki/Microsoft_Library
> #	http://fileformats.archiveteam.org/wiki/OMF
> # Ref.:	http://mark0.net/download/triddefs_xml.7z
> #	defs/l/lib-msvc.trid.xml
> # https://pierrelib.pagesperso-orange.fr/exec_formats/OMF_v1.1.pdf
> 
> I remember the same problems with bad recognition exist also for OMF
> object modules (*.o,*.obj). So i look again at Magdir/xenix how this
> was improved for "8086 relocatable (Microsoft)".
> 
> Because magic is not so strong i put displaying part now inside
> subroutine omf-lib which starts like:
> 
> 0	name			omf-lib
>> 0	byte		0xF0	Microsoft Visual C/OMF library!:mime
>> application/x-omf-lib
> !:ext	lib
> #>1	uleshort	x	\b, 1st record data length %#x
>> 1	uleshort+3	x	\b, page size %u 3	ulelong		x	\b, at %#x
>> dictionary 7	uleshort	x	with %u blocks (1.s+3)	ubyte		x	\b, 2nd
>> record (1.s+3)	ubyte		!0x80	(type %#x)
> 
> In the first byte the OMF record type is stored. For OMF libraries
> this has value 0Fh (LibraryHeaderRecord). Afterwards the first record
> data length is stored a 2 byte integer in little endian. By adding
> three you get the length of the whole first record. Apparently for
> libraries you call it page size. According to documentation page size
> must be multiple of two (page size=2**n). The lowest possible value
> is sixteen (16=2**4) and highest possible value 32768 (=2*15). When
> printing this in hexadecimal this record length looks like ???Dh. So
> the first nibble has always value D. Instead of generic mime type
> application/octet-stream i show a user defined one
> "application/x-omf-lib" and shown file name extension is 3 byte
> string "lib".
> At offset 7 the dictionary size is stored as 2 byte integer as number
> of blocks (a 512 byte). It is written this should be a prime number
> due to the hashing algorithm. For many examples this is often true
> but not always in my inspected examples. It is not explicitly
> written, but when the dictionary size is a multiple of 512 ( that is
> hexadecimal 200), then it obviously make sense that the dictionary
> itself start on such a boundary. So for this dictionary offset value
> stored as 4 byte integer at offset 3 the lowest byte is then always 0
> .
> 
> Now comes the trick to improve recognition. With the help of the
> stored record length it is possible to jump to second record and
> further and inspect the next record. According to specification the
> type of second record is Library Module Header Record (LHEADR=82h),
> but in my inspected examples i found Translator Header Record
> (THEADR=80h), according to documentation this does not hurt because
> the THEADR and LHEADR records are handled identically.
> 
> So now it is time to interpret and update magic lines inside
> Magdir/msvc. The identification happens inside Magdir/msvc by three
> lines like:
> 0	string	\360\015\000\000	Microsoft Visual C library
> 0	string	\360\075\000\000	Microsoft Visual C library
> 0	string	\360\175\000\000	Microsoft Visual C library
> 
> The TrID tool behave similar. It also checks the first 4 bytes but it
> ignores the value in second byte completely. Instead it checks for
> the existence of 4 byte string DATA.
> 
> The first line is for examples with page size 16, The second line
> is for examples with page size 64 and the third line is for examples
> with page size 128. For examples with page size 512 record length is
> 01FDh. So here third byte has value 01 instead of 00. So such
> examples are not recognized. One possible solution would be to add
> lines for maximal 12 variants which look like:
> 0	string	\360\015\000\000
>> 0		use		omf-lib
> 
> Instead the starting lines now becomes like:
> 0	ubelong&0xFF0f80ff	=0xF00d0000
>> (1.s+3)	ubyte&0xFD	=0x80
>>> 0		use		omf-lib
> 
> The first test line is now expressed in a more general way. It test
> that RecordType is as Library Header Record (F0 hexadecimal), record
> length is a hexadecimal number like ???D and dictionary offset is
> multiple of 512 (?????200 hexadecimal and so on). So strength of
> first test is still 70, but now only about 2 and a half bytes are
> used for recognition. By second line the OMF record number 2 is
> checked for valid type (Translator Header Record=THEADR=80h or
> LHEADR=82h). So now about three and a half bytes are used for
> recognition. I hope that this is sufficient. If not then more tests
> for OMF characteristics must be used. That are displayed by sub
> routine.
> 
> With the help of stored dictionary offset i am able to inspect the
> dictionary itself by lines like:
>> (3.l)	ubequad			x	(%#16.16llx...)
> According to documentation the first 37 bytes correspond to the 37
> buckets. Afterwards FFLAG byte is stored. If this has the value 255,
> there is no space left. So i show that value by lines like:
>> (3.l+37)	ubyte		<0xFF	(FFLAG=%#x)
>> (3.l+37)	ubyte		=0xFF	(FFLAG=full)
> Afterwards come dictionary entries in the following form; first
> comes length byte of following symbol, then the following text bytes
> of symbol and then two bytes specifying the page number. So first
> dictionary entry is shown by line like:
>> (3.l+38)	pstring		x	1st entry %s
>>> &0		uleshort	x	in page %u
> So for library ZLIB.LIB i get here "zlibCompileFlags_ in page 1". So
> this may help to identify unknown libraries.
> 
> After the dictionary size a library flag byte is stored. According to
> documentation value one means case sensitive and all bits are
> reserved for future use and should be 0, but for old MOUSE.LIB i
> found here unexpected value 0x4d. So this value maybe can not be used
> as characteristic and is shown by lines like:
>> 9	ubyte			=1	case sensitive
>> 9	ubyte			>1	\b, flags %#x
> 
> The second record is Translator Header Record (THEADR=80h) or Library
> Module Header Record (LHEADR=82h). Here record content consist just
> of one pascal string followed by a checksum byte. This information is
> shown by lines like:
>> (1.s+6)	pstring		x	"%s"
> #>>&0		ubyte		x	checksum %#x
> 
> Often this string is the library module source name like
> "dos\crt0.asm" in mlibce.lib, "QB4UTIL.ASM" in QB4UTIL.LIB or
> "C:\Documents and Settings\Allan Campbell\My Documents\FDOSBoot\
> zlib\zutil.c" in ZLIB.LIB. But the string name can also directly
> specified by the programmer via TITLE pseudo-operand
> or assembler NAME directive. So sometimes i find title like "87INIT"
> in FP87.LIB or "ACOSASIN" in MATHC.LIB or "Copyright" in
> calc-bcc.lib.
> 
> Afterwards comes third record. This inspection starts with lines like
> :
>>> &1		ubyte		x	\b, 3rd record
> #>>&1		ubyte		x	(type %#x)
> 
> For my inspected examples third record type was a List of Names
> Record (LNAMES=96h) or Comment Record (88h~COMENT=88h).
> The LNAMES branch is handled by lines like:
>>> &1		ubyte		=0x96		LNAMES
>>>> &0			uleshort	>2
>>>>> &0			ubyte		=0
>>>>>> &0		pstring		x	%s
>>>>>>> &0		pstring		x	%s
>>>>>>>> &0		ubyte		<44
>>>>>>>>> &-1		pstring		x	%s
> To display only meaningful content some checks must be done. If
> record length is too low (lower three) then there is no content. The
> pascal strings itself can also be empty. This is often the case for
> first LNAME string. The names themselves are used as segment, class,
> group, overlay, and selector names. So here i get typical 4 byte
> strings like CODE (mwlibc.lib) DATA (mwlibc.lib) and longer strings
> like _TEXT32 (JMPPM32.LIB) _OVLCODE (WOVL.LIB) DGROUP (MOUSE.LIB).
> So here we find the word DATA, what is mentioned in TrID definition.
> 
> Now comes problem with used naming. My oldest example was MOUSE.LIB
> dated from September 1984. According to Wikipedia the first
> Visual C compiler suite occur at February 1993. So to become
> general true, the word Visual must be removed from phrase
> "Microsoft Visual C library". According to reference site about
> Microsoft Library
> such libraries would be compiled from source code (BASIC, C,
> Pascal, etc.). That can be verified by example like QB4UTIL.LIB.
> Here second record name is "QB4UTIL.ASM". That means source was
> Assembler code. So the upcase letter C in phrase must be expanded
> to something like "C, Assembler, Pascal, BASIC" or must be removed.
> This library format was not only used by Microsoft but also by
> completely other companies like Borland. This can be seen in
> example CATDB.LIB where third record is a Translator comment like
> "TC86 Borland Turbo C++ 3.00".
> So describing phrase now has shrunken down to just one word library.
> So the correct describing text should look like "relocatable Object
> Module Format (OMF) library". For many examples the old description
> is correct. So to get no total different look i choose a describing
> text like "Microsoft Visual C/OMF library".
> 
> Some libraries are misidentified by Magdir/database as "dBase III
> DBT". Unfortunately xbase memo files have no strong magic, but
> luckily the displaying part is done by subroutine
> dbase3-memo-print. At the end of that sub routine the first memo
> item is shown by line like:
>> 512	string			>\0		\b, 1st item "%s"
> For real examples i get ASCII text like "WHAT IS XBASE" in example
> test.dbt, "Borges, Malte" in biblio.dbt or "First memo\032\032" in
> T2.DBT.
> 
> Before calling this subroutine the first and second character of
> possible first memo item was tested for not "too low" by 2 lines like
> :
>>>>>>>>>>>> 512	ubyte		>037
>>>>>>>>>>>>> 513 ubyte		>037
>>>>>>>>>>>>>> 0	use		dbase3-memo-print
> So bad examples AI070GEP.EPS and
> gluon-ffhat-1.0-tp-link-tl-wr1043n-nd-v2-sysupgrade.bin were skipped.
> 
> To skip also some Microsoft Visual C, OMF library ( like: BZ2.LIB
> WATTCPWL.LIB ZLIB.LIB) i insert a test line for first character "not
> too high" by one additional line. So for libraries with page size
> 512 the second record start at offset 512 with Record Type byte
> (80=THEADR) which can be misinterpreted as dbase memo first item
> starting with \200.
>>>>>>>>>>>> 512	ubyte		>037
>>>>>>>>>>>>> 512 ubyte		<0200
>>>>>>>>>>>>>> 513 ubyte		>037
>>>>>>>>>>>>>>> 0 use		dbase3-memo-print
> 
> Unfortunately most relocatable Object Module Format (OMF) libraries
> are also misidentified as "SysEx File" by Magdir/sysex because
> Library Header Record Type byte (F0h) at the beginning can be
> interpreted as StartSysEx byte (F0h). Afterwards the library first
> record length is interpreted as MIDI vendor ID. So all libraries with
> record length 1Dh ( +3= 32 page size) are described by MIDI vendor
> name "Inventronics" and all libraries with record length 0Dh ( +3= 16
> page size) are described by MIDI vendor name "ADA". For libraries
> with page size 512 (That is record length 1FD) second byte is FD. So
> here the upper bit is set. That is not true for MIDI SysEx. So such
> libraries are not misidentified by magic lines inside Magdir/sysex.
> The description happens by lines that look like:
> 
> 0	ubeshort&0xFF80		0xF000		SysEx File -
>> 1	byte			0x01		Sequential
>> 1	byte			0x02		IDP
>> 1	byte			0x03		OctavePlateau
> ..
>> 1	byte			0x0d		ADA
> ..
>> 1	byte			0x1d		Inventronics
>> 1	byte			0x57		Acoustic tech. lab.
> 
> So this now becomes like:
> 0	ubeshort&0xFF80		0xF000
> #!:strength +0
>> 2		search/11	\xF7
>>> 0	use	midi-sysex
> 0	name	midi-sysex
> #>1	ubyte	x SysEx File -
>> 1	ubyte	x MIDI audio System Exclusive (SysEx) message  -
> !:mime	audio/x-syx
> !:ext	syx/sysex
>> 1	byte	0x01		Sequential
>> 1	byte	0x02		IDP
> ...
>> 1	byte	0x66		MIDI Emulator
> 
> First i put displaying part inside sub routine midi-sysex.
> 
> After test for StartSysEx byte and upper unused bit of vendor ID it
> is possible to add more test lines (like i do later to distinguish
> SysEx from OMF libraries) or change the unspecific test.
> 
> With --list option i look at the reported strength of patterns for
> LIB and SYX examples. The MIDI System Exclusive (SysEx) messages
> with strength=50 comes after Microsoft Visual C library with
> strength=70. This is OK i think, but if not then the total strength
> value can be raised or lowered by adding or subtracting integers in
> order to shift description texts.
> 
> Furthermore i changed description text "SysEx File" because it was
> for myself and probably the users irritating. I read this as "sy sex"
> which sounds like a sexual practice or behaviour. But it is the
> technical term used and known by audio experts but not by normal
> users. This is the abbreviation for "System Exclusive". So the
> inspected files are System Exclusive messages to control MIDI audio
> devices. So i look how others call such files. The page about SYX
> file extension on web site fileinfo.com use description "MIDI System
> Exclusive Message". The page all about SYX files on filext.com use
> text "SysEx MIDI File". So i finally choose "MIDI audio System
> Exclusive (SysEx) message". If you are in circles about audio and
> computers you probably know the phrase MIDI, but my sister working in
> buero at PC did not know that term. So instead of generic mime type
> application/octet-stream i also add a user defined one belonging to
> main class audio.
> 
> According to page about "System Exclusive Files" on onsongapp.com
> also the second file extension sysex can be used instead of 3 byte
> SYX.
> 
> According to MIDI file specification after StartSysEx byte comes n
> bytes data. Afterwards comes a required "End of Exclusive" (EOX=0F7)
> byte. When searching the net for information i read text, that some
> not well behaved software does not terminate data bytes, but in my
> dozen inspected examples terminating byte was OK and EOX byte occur
> only a few bytes later. So the misidentified OMF libraries are
> skipped by second additional test line that looks like:
>> 2		search/12	\xF7
> But i do not know if this is always true, but i think it is better to
> skip many misidentified and maybe mismatch a few SYX examples. So for
> control reasons at the end of the sub routine i display information
> about EOX byte (F7h) by lines like:
>> 4	ubyte			0xF7		\b, at 4 EOX
>> 5	ubyte			0xF7		\b, at 5 EOX
> ...
>> 13	ubyte			0xF7		\b, at 13 EOX
>> 14	ubyte			0xF7		\b, at 14 EOX
> 
> For many examples after the hyphen character the vendor id name like
> Apple or Yamaha is shown by inspecting the next 1 or 3 bytes.
> Unfortunately for a few samples like example-1manband.syx
> example-syxcom.syx and example-webmidijs.syx nothing is shown here.
> When looking in Magdir/sysex as part of file version 5.41 i see that
> this text file has a version number of 1.10 and is dated with April
> 2019. On web site midi.org i found a page with assigned manufacturer
> MIDI SysEx ID numbers dated with March 2021 and on GitHub i a found a
> CSV table with MIDI Sysex manufacture IDs. By such information
> sources i added lines for unrecognized IDs, but i only check the 1
> byte manufacture numbers. These additional part looks like:
> 
>> 1	byte			0x00		ID EXTENSIONS
>> 1	byte			0x13		Digidesign Inc.
>> 1	byte			0x1e		Key Concepts
>> 1	byte			0x20		Passac
> ..
>> 1	byte			0x66		MIDI Emulator
>> 1	byte			0x7D		PROTOTYPING
>> 1	byte			0x7E		UNIVERSAL
>> 1	byte			0x7F		universal real time
> 
> Then there are a few entries where manufacture in newer documentation
> are different. I do not know the reasons, but probably the company is
> by bought another and so name changed. Such things are expressed by
> lines like:
> 
> #>1	byte			0x03		OctavePlateau
>> 1	byte			0x03		Voyetra Turtle Beach
> #>1	byte			0x09		Gulbransen
>> 1	byte			0x09		MIDI9
> #>1	byte			0x26		Solton
>> 1	byte			0x26		Ketron s.r.l.
> #>1	byte			0x31		Jomox
>> 1	byte			0x31	Viscount International Spa
> 
> In some cases in current lines the id name is an abbreviation or
> such a general term, that it gives a wrong direction of meaning.
> I will illustrate this. For me Garfield is a comic cat. So files with
> ID 0e are described as "SysEx File - Garfield". So for me that sound
> like the second phrase is the main part. So i interpret this as the
> sysex of the Garfield cat. So when using the full name mentioned in
> newer documents "Garfield Electronics" it becomes clear that this
> impression is wrong. Examples with id 2b are described as "SysEx File
> - - SSL". For me this sounds like a module or method of the SSL
> decryption library. So with full "Solid State Logic Organ Systems"
> this misinterpretation vanish. Examples with id 0d are described as
> "SysEx File - ADA". When i hear ADA i get association with the ADA
> programming language. So for me this sounds like module or format
> example belonging to ADA programming language. With the full name
> "ADA Signal Processors Inc." this misinterpretation becomes
> destroyed. Often by appended phrase Ltd, GmbH or Inc it becomes clear
> that we are talking about company names. So such changed things are
> now expressed by lines like:
> #>1	byte			0x01		Sequential
>> 1	byte			0x01		Sequential Circuits
> #>1	byte			0x05		Passport
>> 1	byte			0x05		Passport Designs
> #>1	byte			0x06		Lexicon
>> 1	byte			0x06		Lexicon Inc.
> #>1	byte			0x0a		AKG
>> 1	byte			0x0a		AKG Acoustics
> #>1	byte			0x0d		ADA
>> 1	byte			0x0d	ADA Signal Processors Inc.
> #>1	byte			0x0e		Garfield
>> 1	byte			0x0e		Garfield Electronics
> #>1	byte			0x19		Harmony
>> 1	byte			0x19		Harmony Systems
> #>1	byte			0x21		SIEL
>> 1	byte			0x21		Proel Labs (SIEL)
> #>1	byte			0x2b		SSL
>> 1	byte			0x2b Solid State Logic Organ Systems
> 
> After applying the above mentioned modifications by patches
> file-5.41-msvc-lib.diff, file-5.41-database-lib.diff and
> file-5.41-sysex-lib.diff then i get a more correct output with more
> details like:
> 
> CATDB.LIB:                  Microsoft Visual C/OMF library,
> 			    page size 16, at 0x1200 dictionary with
> 			    1 block (FFLAG=0x67) 1st entry
> 			    CATGETS! in page 57,
> 			    2nd record
> 			    "DB",
> 			    3rd record COMMENT class=0 Translator
> 			    "TC86 Borland Turbo C++ 3.00"
> DBFNTX.LIB:                 Microsoft Visual C/OMF library,
> 			    page size 32, at 0x18200 dictionary with
> 			    1 block (FFLAG=0x37) 1st entry
> 			    dbfntx1! in page 1
> 			    case sensitive,
> 			    2nd record
> 			    "C:\XHARBOUR\SRC\SOURCE\RDD\DBFNTX\
> 			    dbfntx1.c",
> 			    3rd record COMMENT Preserved class=0xaa
> FLIB7M.LIB:                 Microsoft Visual C/OMF library,
> 			    page size 512, at 0x44a00 dictionary with
> 			    31 blocks (FFLAG=0xf7) 1st entry
> 			    IF at XQABS in page 41,
> 			    2nd record
> 			    "fsystem",
> 			    3rd record COMMENT Preserved class=0xa1
> FP87.LIB:                   Microsoft Visual C/OMF library,
> 			    page size 16, at 0xa00 dictionary with
> 			    1 block (FFLAG=0x60) 1st entry
> 			    87INIT! in page 1,
> 			    2nd record
> 			    "87INIT",
> 			    3rd record LNAMES
> JMPPM32.LIB:                Microsoft Visual C/OMF library,
> 			    page size 16, at 0x600 dictionary with
> 			    2 blocks (FFLAG=0x23) 1st entry
> 			    __movehigh at 0 in page 47,
> 			    2nd record
> 			    "getcmdl.asm",
> 			    3rd record LNAMES _TEXT32 CODE
> LIBFL.LIB:                  Microsoft Visual C/OMF library,
> 			    page size 16, at 0x600 dictionary with
> 			    2 blocks (FFLAG=0x34) 1st entry
> 			    yy_flex_free in page 1
> 			    case sensitive,
> 			    2nd record
> 			    "liballoc.obj",
> 			    3rd record COMMENT Preserved class=0xa1
> 			    New OMF extensions n=3 IBM style
> MOUSE.LIB:                  Microsoft Visual C/OMF library,
> 			    page size 512, at 0x800 dictionary with
> 			    1 block (FFLAG=0x26) 1st entry
> 			    MOUSE in page 1, flags 0x4d,
> 			    2nd record
> 			    "MOUSE",
> 			    3rd record LNAMES CODE DATA DGROUP
> PRESET_6.SYX:               MIDI audio System Exclusive (SysEx)
> 			    message - MIDI Emulator, at 4 EOX
> QB4UTIL.LIB:                Microsoft Visual C/OMF library,
> 			    page size 16, at 0x400 dictionary with
> 			    1 block (FFLAG=0x38) 1st entry
> 			    ASCIIDISPLAY in page 1,
> 			    2nd record
> 			    "QB4UTIL.ASM",
> 			    3rd record COMMENT class=0xa3
> 			    LIBMOD qb4util
> REXX.LIB:                   Microsoft Visual C/OMF library,
> 			    page size 16, at 0x1800 dictionary with
> 			    5 blocks (FFLAG=0x96) 1st entry
> 			    RXEXITREGISTER in page 31,
> 			    2nd record
> 			    "REXXSAA",
> 			    3rd record COMMENT class=0xa0
> 			    OMF extensions IMPDEF ordinal
> 			    REXXSAA exported by REXX
> T2.DBT:                     dBase III DBT, next free block index 11,
> 			    1st item "First memo\032\032"
> WATTCPWL.LIB:               Microsoft Visual C/OMF library,
> 			    page size 512, at 0x46000 dictionary with
> 			    23 blocks (FFLAG=full) 1st entry
> 			    _w32_millisec_clock_ in page 33
> 			    case sensitive,
> 			    2nd record
> 			    "C:\watcom\watt32\src\version.c",
> 			    3rd record COMMENT Preserved class=0xa1
> ZLIB.LIB:                   Microsoft Visual C/OMF library,
> 			    page size 512, at 0x2ce00 dictionary with
> 			    3 blocks (FFLAG=0xc6) 1st entry
> 			    zlibCompileFlags_ in page 1
> 			    case sensitive,
> 			    2nd record
> 			    "C:\Documents and Settings\Allan Campbell
> 			    \My Documents\FDOSBoot\zlib\zutil.c",
> 			    3rd record COMMENT Preserved class=0xa1
> example-1manband.syx:       MIDI audio System Exclusive (SysEx)
> 			    message - UNIVERSAL, at 5 EOX
> example-apple.syx:          MIDI audio System Exclusive (SysEx)
> 			    message - Apple, at 4 EOX
> example-chromakinetics.syx: MIDI audio System Exclusive (SysEx)
> 			    message - Roland, at 14 EOX
> example-roland.syx:         MIDI audio System Exclusive (SysEx)
> 			    message - Roland, at 13 EOX
> example-somascape2.syx:     MIDI audio System Exclusive (SysEx)
> 			    message - UNIVERSAL, at 5 EOX
> example-syxcom.syx:         MIDI audio System Exclusive (SysEx)
> 			    message - ID EXTENSIONS, at 10 EOX
> example-webmidijs.syx:      MIDI audio System Exclusive (SysEx)
> 			    message - PROTOTYPING, at 8 EOX
> example-yamaha.syx:         MIDI audio System Exclusive (SysEx)
> 			    message - Yamaha, at 8 EOX
> mlibce.lib:                 Microsoft Visual C/OMF library,
> 			    page size 16, at 0x2b400 dictionary with
> 			    31 blocks (FFLAG=0xde) 1st entry
> 			    $i4_m4 in page 8783,
> 			    2nd record
> 			    "dos\crt0.asm",
> 			    3rd record COMMENT class=0xa3 LIBMOD crt0
> mwlibc.lib:                 Microsoft Visual C/OMF library,
> 			    page size 16, at 0x15a00 dictionary with
> 			    17 blocks (FFLAG=0x93) 1st entry
> 			    atoi! in page 458,
> 			    2nd record
> 			    "_exit",
> 			    3rd record LNAMES CODE DATA DGROUP
> unrar-bcc.lib:              Microsoft Visual C/OMF library,
> 			    page size 16, at 0x400 dictionary with
> 			    1 block (FFLAG=0x84) 1st entry
> 			    RARCloseArchive in page 6,
> 			    2nd record
> 			    "DllGetVersion",
> 			    3rd record COMMENT class=0xa0
> 			    OMF extensions IMPDEF
> 			    DllGetVersion exported by unrar3.dll
> 
> I hope my three diff files can be applied in future version of
> file utility.
> 
> With best wishes
> Jörg Jenderek
> - --
> Jörg Jenderek
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYeN2MAAKCRCv8rHJQhrU
> 1grVAKC/VBJ1l0qBPrarc1tHKRBYexfoPACcC0mB6HAFzVnujoDxQPLMp29fj08=
> =OPSA
> -----END PGP SIGNATURE-----
> <file-5_41-database-lib_diff.DEFANGED-4752><file-5_41-database-lib_diff_sig.DEFANGED-4753><file-5_41-sysex-lib_diff.DEFANGED-4754><file-5_41-sysex-lib_diff_sig.DEFANGED-4755><file-5_41-msvc-lib_diff.DEFANGED-4756><file-5_41-msvc-lib_diff_sig.DEFANGED-4757><lib_syx-trid-v.txt.gz>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20220117/29e5c85f/attachment-0001.asc>


More information about the File mailing list