[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