[File] [PATCH] of Magdir/msvc, database, sysex for Microsoft Visual C or OMF library *.LIB
Jörg Jenderek
joerg.jen.der.ek at gmx.net
Sun Jan 16 01:34:58 UTC 2022
-----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-----
-------------- next part --------------
--- file-5.41/magic/Magdir/database.old 2021-10-18 14:20:03 +0000
+++ file-5.41/magic/Magdir/database 2022-01-01 17:47:22 +0000
@@ -416,7 +416,9 @@
# skip AI070GEP.EPS by printable 1st character of 1st memo item
>>>>>>>>>>>512 ubyte >037
+# skip some Microsoft Visual C, OMF library like: BZ2.LIB WATTCPWL.LIB ZLIB.LIB
+>>>>>>>>>>>>512 ubyte <0200
# skip gluon-ffhat-1.0-tp-link-tl-wr1043n-nd-v2-sysupgrade.bin by printable 2nd character
->>>>>>>>>>>>513 ubyte >037
->>>>>>>>>>>>>0 use dbase3-memo-print
+>>>>>>>>>>>>>513 ubyte >037
+>>>>>>>>>>>>>>0 use dbase3-memo-print
# dBASE IV DBT with positive block size
>>>>>>>20 uleshort >0
@@ -441,5 +443,8 @@
>20 uleshort !0 \b, block length %u
# dBase III memo field terminated by \032\032
+# like: "WHAT IS XBASE" test.dbt "Borges, Malte" biblio.dbt "First memo\032\032" T2.DBT
>512 string >\0 \b, 1st item "%s"
+# For DEBUGGING
+#>512 ubelong x \b, 1ST item %#8.8x
# https://www.clicketyclick.dk/databases/xbase/format/dbt.html
# Print the information of dBase IV DBT memo file
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.41-database-lib.diff.sig
Type: application/octet-stream
Size: 779 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220116/e76e5e38/attachment-0003.obj>
-------------- next part --------------
--- file-5.41/magic/Magdir/sysex.old 2020-05-31 10:34:41 +0000
+++ file-5.41/magic/Magdir/sysex 2022-01-16 00:05:47 +0000
@@ -8,11 +8,33 @@
# https://en.wikipedia.org/wiki/MIDI
-0 ubeshort&0xFF80 0xF000 SysEx File -
-
+# test for StartSysEx byte and upper unsed bit of vendor ID
+0 ubeshort&0xFF80 0xF000
+# MIDI System Exclusive (SysEx) messages (strength=50) after Microsoft Visual C library (strength=70)
+#!:strength +0
+# skip Microsoft Visual C library with page size 16 misidentifed as ADA and
+# page size 32 misidentifed as Inventronics by looking for terminating End Of eXclusive byte (EOX)
+>2 search/12 \xF7
+>>0 use midi-sysex
+# display information about MIDI System Exclusive (SysEx) messages
+0 name midi-sysex
+# https://fileinfo.com/extension/syx
+>1 ubyte x MIDI audio System Exclusive (SysEx) message -
+# Note: file (version 5.41) labeled the above entry as "SysEx File"
+#!:mime application/octet-stream
+!:mime audio/x-syx
+# https://onsongapp.com/docs/features/formats/sysex
+!:ext syx/sysex
+# https://www.midi.org/specifications-old/item/manufacturer-id-numbers
+# https://raw.githubusercontent.com/insolace/MIDI-Sysex-MFG-IDs/master/Sysex%20ID%20Tables/MIDI%20Sysex%20MFG%20IDs.csv
+# SysEx manufacturer ID; originally one byte, but now 0 is used as an escapement to reach the next two
# North American Group
->1 byte 0x01 Sequential
+#>1 byte 0x01 Sequential
+>1 byte 0x01 Sequential Circuits
>1 byte 0x02 IDP
->1 byte 0x03 OctavePlateau
+#>1 byte 0x03 OctavePlateau
+>1 byte 0x03 Voyetra Turtle Beach
>1 byte 0x04 Moog
->1 byte 0x05 Passport
->1 byte 0x06 Lexicon
+#>1 byte 0x05 Passport
+>1 byte 0x05 Passport Designs
+#>1 byte 0x06 Lexicon
+>1 byte 0x06 Lexicon Inc.
>1 byte 0x07 Kurzweil/Future Retro
@@ -40,8 +62,13 @@
>1 byte 0x08 Fender
->1 byte 0x09 Gulbransen
->1 byte 0x0a AKG
+#>1 byte 0x09 Gulbransen
+>1 byte 0x09 MIDI9
+#>1 byte 0x0a AKG
+>1 byte 0x0a AKG Acoustics
>1 byte 0x0b Voyce
>1 byte 0x0c Waveframe
->1 byte 0x0d ADA
->1 byte 0x0e Garfield
+# not ADA programming language
+#>1 byte 0x0d ADA
+>1 byte 0x0d ADA Signal Processors Inc.
+#>1 byte 0x0e Garfield
+>1 byte 0x0e Garfield Electronics
>1 byte 0x0f Ensoniq
@@ -61,3 +88,4 @@
>1 byte 0x18 E-mu
->1 byte 0x19 Harmony
+#>1 byte 0x19 Harmony
+>1 byte 0x19 Harmony Systems
>1 byte 0x1a ART
@@ -69,3 +97,4 @@
# European Group
->1 byte 0x21 SIEL
+#>1 byte 0x21 SIEL
+>1 byte 0x21 Proel Labs (SIEL)
>1 byte 0x22 Synthaxe
@@ -73,3 +102,4 @@
>1 byte 0x25 Twister
->1 byte 0x26 Solton
+#>1 byte 0x26 Solton
+>1 byte 0x26 Ketron s.r.l.
>1 byte 0x27 Jellinghaus
@@ -78,4 +108,6 @@
>1 byte 0x2a JEN
->1 byte 0x2b SSL
->1 byte 0x2c AudioVertrieb
+#>1 byte 0x2b SSL
+>1 byte 0x2b Solid State Logic Organ Systems
+#>1 byte 0x2c AudioVertrieb
+>1 byte 0x2c Audio Veritrieb-P. Struven
@@ -85,3 +117,4 @@
>1 byte 0x30 Dynacord
->1 byte 0x31 Jomox
+#>1 byte 0x31 Jomox
+>1 byte 0x31 Viscount International Spa
>1 byte 0x33 Clavia
@@ -204,3 +237,4 @@
>1 byte 0x47 Akai
->1 byte 0x48 Victor
+#>1 byte 0x48 Victor
+>1 byte 0x48 Victor Company of Japan. Ltd.
>1 byte 0x49 Mesosha
@@ -211,3 +245,4 @@
>1 byte 0x51 Fostex
->1 byte 0x52 Zoom
+#>1 byte 0x52 Zoom
+>1 byte 0x52 Zoom Corporation
>1 byte 0x54 Matsushita
@@ -319,2 +354,76 @@
+# Update: Joerg Jenderek; January 2022
+>1 byte 0x00 ID EXTENSIONS
+>1 byte 0x13 Digidesign Inc.
+>1 byte 0x1e Key Concepts
+>1 byte 0x20 Passac
+>1 byte 0x23 Stepp
+>1 byte 0x2d Neve
+>1 byte 0x2e Soundtracs Ltd.
+>1 byte 0x32 Drawmer
+>1 byte 0x34 Audio Architecture
+>1 byte 0x35 Generalmusic Corp SpA
+>1 byte 0x36 Cheetah Marketing
+>1 byte 0x37 C.T.M.
+>1 byte 0x38 Simmons UK
+>1 byte 0x3a Steinberg
+>1 byte 0x3b Wersi GmbH
+>1 byte 0x3c AVAB Niethammer AB
+>1 byte 0x3d Digigram
+>1 byte 0x3f Quasimidi
+#
+>1 byte 0x40 Kawai Musical Instruments MFG. CO. Ltd
+#>1 byte 0x45 foo
+#>1 byte 0x4a foo
+#>1 byte 0x4d foo
+#>1 byte 0x4f foo
+#>1 byte 0x53 foo
+>1 byte 0x55 Suzuki Musical Instruments MFG. Co. Ltd.
+>1 byte 0x56 Fuji Sound Corporation Ltd.
+#>1 byte 0x58 foo
+>1 byte 0x59 Faith. Inc.
+>1 byte 0x5a Internet Corporation
+#>1 byte 0x5b foo
+>1 byte 0x5c Seekers Co. Ltd.
+#>1 byte 0x5d foo
+#>1 byte 0x5e foo
+>1 byte 0x5f SD Card Association
+# Reserved for other uses for 60H to 7FH
+# URL: https://www.philscomputerlab.com/roland-midi-emulator-project-20.html
+# Reference: http://mark0.net/download/triddefs_xml.7z/defs/s/syx--midiemu.trid.xml
+# Note: called by TrID "MIDI Emulator Project SysEx preset command"
+>1 byte 0x66 MIDI Emulator
+# https://electronicmusic.fandom.com/wiki/List_of_MIDI_Manufacturer_IDs
+# Educational, prototyping, test, private use and experimentation
+>1 byte 0x7D PROTOTYPING
+# universal non-real-time (sample dump, tuning table, etc.)
+>1 byte 0x7E UNIVERSAL
+# universal real time (MIDI time code, MIDI Machine control, etc.)
+>1 byte 0x7F universal real time
+# display information about End Of eXclusive byte (EOX=F7)
+#>2 ubyte 0xF7 \b, at 2 EOX
+#>3 ubyte 0xF7 \b, at 3 EOX
+# https://tttapa.github.io/Control-Surface-doc/new-input/Doxygen/d2/d93/SysEx-Send-Receive_8ino-example.html
+>4 ubyte 0xF7 \b, at 4 EOX
+# http://www.1manband.nl/tutorials2/sysex.htm
+>5 ubyte 0xF7 \b, at 5 EOX
+# http://www.somascape.org/midi/tech/mfile.html#sysex
+>6 ubyte 0xF7 \b, at 6 EOX
+#
+>7 ubyte 0xF7 \b, at 7 EOX
+# https://webmidijs.org/forum/discussion/34/how-to-send-or-receive-system-exclusive-messages
+>8 ubyte 0xF7 \b, at 8 EOX
+#
+>9 ubyte 0xF7 \b, at 9 EOX
+# https://www.chd-el.cz/wp-content/uploads/845010_syxcom.pdf
+>10 ubyte 0xF7 \b, at 10 EOX
+# https://stackoverflow.com/questions/52906076/handling-midi-the-input-of-multiple-system-exclusive-messages-in-vb
+>11 ubyte 0xF7 \b, at 11 EOX
+# https://www.2writers.com/eddie/TutSysEx.htm
+>12 ubyte 0xF7 \b, at 12 EOX
+>13 ubyte 0xF7 \b, at 13 EOX
+# http://www.chromakinetics.com/handsonic/rolSysEx.htm
+>14 ubyte 0xF7 \b, at 14 EOX
+#>15 ubyte 0xF7 \b, at 15 EOX
+
0 string T707 Roland TR-707 Data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.41-sysex-lib.diff.sig
Type: application/octet-stream
Size: 2814 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220116/e76e5e38/attachment-0004.obj>
-------------- next part --------------
--- file-5.41/magic/Magdir/msvc.old 2020-05-31 10:34:40 +0000
+++ file-5.41/magic/Magdir/msvc 2022-01-16 00:50:19 +0000
@@ -22,5 +22,158 @@
#.lib
-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
+# URL: https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B
+# http://fileformats.archiveteam.org/wiki/Microsoft_Library
+# http://fileformats.archiveteam.org/wiki/OMF
+# Reference: http://mark0.net/download/triddefs_xml.7z/defs/l/lib-msvc.trid.xml
+# https://pierrelib.pagesperso-orange.fr/exec_formats/OMF_v1.1.pdf
+# Update: Joerg Jenderek
+#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
+# test for RecordType~LibraryHeaderRecord=0xF0 + RecordLength=???Dh + dictionary offset is multiple of 0x200
+0 ubelong&0xFF0f80ff =0xF00d0000
+# Microsoft Visual C library (strength=70) before MIDI SysEx messages (strength=50) handled by ./sysex
+#!:strength +0
+# test for valid 2nd RecordType~Translator Header Record=THEADR=80h or LHEADR=82h
+>(1.s+3) ubyte&0xFD =0x80
+>>0 use omf-lib
+# display information about Microsoft Visual C/OMF library
+0 name omf-lib
+# RecordType~LibraryHeaderRecord=0xF0
+#>0 byte 0xF0 Microsoft Visual C library
+# the above description was used in file version 5.41
+>0 byte 0xF0 Microsoft Visual C/OMF library
+#>0 byte 0xF0 relocatable Object Module Format (OMF) libray
+#!:mime application/octet-stream
+!:mime application/x-omf-lib
+!:ext lib
+# 1st record data length like 13=0Dh 29=1Dh 61=3Dh 125=7Dh 509=01FDh ... 32765=7FFDh
+#>1 uleshort x \b, 1st record data length %u
+#>1 uleshort x \b, 1st record data length %#x
+# 2**4=16 <= RecordLength+3 = PageSize = 2**n {16 32 512 no examples 64 128 256 1024 2048 ...32768} <= 2**15=32768
+>1 uleshort+3 x \b, page size %u
+# dictionary offset like: 400h 600h a00h c00h 1200h 1800h 2400h 5600h 12800h 19200h 28a00h
+>3 ulelong x \b, at %#x dictionary
+# dictionary block a 512 bytes; the first 37 bytes correspond to the 37 buckets
+#>(3.l) ubequad x (%#16.16llx...)
+# dictionary size; length in 512-byte blocks; a prime number? like:
+# 1 2 3 4 5 6 7 9 11 13 15 16 18 21 22 23 24 25 31 50 53 89 101 117 277
+>7 uleshort x with %u block
+# plurals s
+>7 uleshort >1 \bs
+# If dictionary byte 38 (FFLAG) has the value 255, there is no space left
+>(3.l+37) ubyte <0xFF (FFLAG=%#x)
+>(3.l+37) ubyte =0xFF (FFLAG=full)
+# dictionary entry; length byte of following symbol, the following text bytes of symbol, two bytes specifies the page number
+# like: dbfntx1! DBFNTX.LIB zlibCompileFlags_ ZLIB.LIB atoi! mwlibc.lib
+>(3.l+38) pstring x 1st entry %s
+# like: 1 33 41 47 458 8783
+>>&0 uleshort x in page %u
+# library flags; 0 or 1, but WHAT IS 0x4d in MOUSE.LIB ?
+>9 ubyte >1 \b, flags %#x
+>9 ubyte =1 case sensitive
+# In the library after header comes first object module with a Library Module Header Record (LHEADR=82h)
+# but in examples Translator Header Record (THEADR=80h) which is handled identically
+>(1.s+3) ubyte x \b, 2nd record
+>(1.s+3) ubyte !0x80 (type %#x)
+#>(1.s+4) uleshort x \b, 2nd record data length %u
+# Module name often source name like "dos\crt0.asm" in mlibce.lib or "QB4UTIL.ASM" in QB4UTIL.LIB
+# or "C:\Documents and Settings\Allan Campbell\My Documents\FDOSBoot\zlib\zutil.c" in ZLIB.LIB
+# or title like "87INIT" in FP87.LIB or "ACOSASIN" in MATHC.LIB or "Copyright" in calc-bcc.lib
+>(1.s+6) pstring x "%s"
+# 2nd record checksum
+#>>&0 ubyte x checksum %#x
+# 3rd RecordType: 96h~LNAMES 88h~COMENT
+>>&1 ubyte x \b, 3rd record
+>>&1 ubyte !0x88
+>>>&-1 ubyte !0x96
+# 3rd unusual record type
+>>>>&-1 ubyte x (type %#x)
+# 3rd record is a List of Names Record (LNAMES=96h)
+>>&1 ubyte =0x96 LNAMES
+# LNAMES record length like: 2 15 19
+#>>>&0 uleshort x \b, LNAMES record length %u
+>>>&0 uleshort >2
+# 1st LNAME string length; null is valid; maximal 255
+#>>>>&0 ubyte x 1st LNAME length %u
+>>>>&0 ubyte =0
+# 2nd LNAME length like: 4 7 8 17 31
+#>>>>>&0 ubyte x 2nd LNAME length %u
+# name used for segment, class, group, overlay, etc like:
+# CODE (mwlibc.lib) _TEXT32 (JMPPM32.LIB) _OVLCODE (WOVL.LIB)
+>>>>>&0 pstring x %s
+# 3rd LNAME length like: 4 5
+#>>>>>>&0 ubyte x 3rd LNAME length %u
+# like: DATA (mwlibc.lib) CODE (JMPPM32.LIB) _TEXT (EMU87.LIB)
+>>>>>>&0 pstring x %s
+# maybe 4th LNAME length like: 4 6
+>>>>>>>&0 ubyte <44
+# like: DATA (DEBUG.LIB) DGROUP (mwlibc.lib MOUSE.LIB)
+>>>>>>>>&-1 pstring x %s
+# 3rd record is a COMMENT (Including all comment class extensions)
+>>&1 ubyte =0x88 COMMENT
+# comment record length like: 3 FLIB7M.LIB 1Bh 1Eh 23h 27h 2Bh 30h freetype-bcc.lib
+#>>>&0 uleshort x \b, record length %#x
+# real comment length = record length - 1 (comment type) - 1 (comment Class) - 1 (checksum) -1 (char count)
+# like: 2 LIBFL.LIB 4 "UUID" 5 "dscap" 6 "int386" 7 "qb4util" 8 "AMSGEXIT" 16 REXX.LIB 20 27 35 44 freetype-bcc.lib
+#>>>>&-2 uleshort-4 >0 \b, comment length %u
+# check that record contain at least comment type (1 byte), comment class (1 byte), checksum (1 byte)
+# probably always true
+>>>&0 uleshort >2
+# comment type: 80h~NP~no purge bit 40h~NL~no list bit
+#>>>>&0 ubyte !0 Type %#x
+>>>>&0 ubyte &0x80 Preserved
+# no example
+>>>>&0 ubyte &0x40 NoList
+# comment class like: 0~Translator A0~OMF extensions A3~LIBMOD A1~New OMF extensions AA~UNKNOWN
+>>>>&1 ubyte x class=%#x
+# check that comment record contains at least real content
+>>>>&-2 uleshort >3
+# Translator comment record (0); it may name the source language or translator
+>>>>>&1 ubyte =0 Translator
+#>>>>>>&0 ubyte x Translator length %u
+# like: "TC86 Borland Turbo C 2.01 " (GEMS.LIB) "TC86 Borland Turbo C++ 3.00" (CATDB.LIB)
+>>>>>>&0 pstring x "%s"
+# OMF extensions comment record (A0); first byte of commentary string identifies subtype
+>>>>>&1 ubyte =0xA0 OMF extensions
+# A0 subtype like: 1~IMPDEF
+>>>>>>&0 ubyte !1 subtype %#x
+# Import Definition Record (Comment Class A0, Subtype 01~IMPDEF)
+>>>>>>&0 ubyte 1 IMPDEF
+# ordinal flag; determines form of Entry Ident field. If nonzero (seems to be 1) Entry is ordinal
+>>>>>>>&0 ubyte !0 ordinal
+# like: IMPORT.LIB DOSCALLS.LIB mlibw.lib mwinlibc.lib REXX.LIB
+>>>>>>>>&-1 ubyte >1 %u
+# Internal Name in count, char string format; module name for the imported symbol
+# like: 7 "REXXSAA" 9 11 13 14 15 16 20 21 26 "_Z10_clip_linePdS_S_S_dddd"
+#>>>>>>>&1 ubyte x internal name length %u
+# internal module name like: _DllGetVersion DllGetVersion BezierTerminationTest Copyright
+>>>>>>>&1 pstring x %s
+# module name in count, char string format; DLL name that supplies a matching export symbol
+# like: jpeg62.dll (jpeg-bcc.lib) unrar3.dll (unrar-bcc.lib) REXX (REXX.LIB)
+>>>>>>>>&0 pstring x exported by %s
+# Entry Ident; 16-bit if ordinal flag != 0 or imported name in count, char string format if ordinal flag = 0
+# like: \0 (calc-bcc.lib) DllGetVersion (libtiff-bcc.lib) UTF8ToHtml (libxml2-bcc.lib) xslAddCall (libxslt-bcc.lib)
+#>>>>>>>>>&0 pstring >\0 entry ident %s
+# "New OMF" extensions comment (A1); indicate version of symbolic debug information
+# like: LIBFL.LIB
+>>>>>&1 ubyte =0xA1 New OMF extensions
+# symbolic debug information version n
+>>>>>>&0 ubyte x n=%u
+# symbolic debug information style like: HL~IBM PM Debugger style (LIBFL.LIB) DX~AIX style CV~Microsoft symbol and type style
+>>>>>>>&0 string HL IBM style
+>>>>>>>&0 string DX AIX style
+>>>>>>>&0 string CV Microsoft style
+# LIBMOD comment record (A3) used only by the librarian
+# Microsoft extension added for LIB version 3.07 in macro assembler (MASM 5.0)
+>>>>>&1 ubyte =0xA3 LIBMOD
+# The A3 LIBMOD record contains only the ASCII string of the module name in count char format
+#>>>>>>&0 ubyte x LIBMOD length %u
+# LIBMOD comment record module name without path and extension like:
+# qb4util (QB4UTIL.LIB) affaldiv (libh.lib) crt0 (slibc.lib) clipper (DDDRAWS.LIB) dinpdev (DINPUTS.LIB) UUID (UUID.LIB)
+>>>>>>&0 pstring x %s
+# GRR: WHAT iS THAT? AA foo comment record
+#>>>>>&1 ubyte =0xAA AA-comment
+# like: OS220
+#>>>>>>&0 string x what=%-5.5s
+#
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.41-msvc-lib.diff.sig
Type: application/octet-stream
Size: 3642 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220116/e76e5e38/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lib_syx-trid-v.txt.gz
Type: application/x-gzip
Size: 681 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220116/e76e5e38/attachment-0001.bin>
More information about the File
mailing list