Category : File Managers
Archive   : AF125.ZIP
Filename : AF.INF
Annexe la documentation de AF.EXE
---------------------------------------------------------------------------
Ce fichier contient la totalit des informations ma disposition pour
la cration de ce programme. Il pourra vous tre utile un jour, peut-tre.
---------------------------------------------------------------------------
-----------------------------
ARJ - Extrait de TECHNOTE.DOC
-----------------------------
ARJ archives contains two types of header blocks:
Archive main header - This is located at the head of the archive
Local file header - This is located before each archived file
Structure of archive block (low order byte first):
Bytes Description
----- -------------------------------------------------------------------
2 header id (main and local file) = 0xEA60 or 60000U
2 basic header size (from 'first_hdr_size' thru 'comment' below)
= first_hdr_size + strlen(filename) + 1 + strlen(comment) + 1
= 0 if end of archive
1 first_hdr_size (size up to and including 'extra data')
1 archiver version number
1 minimum archiver version to extract
1 host OS (0 = MSDOS, 1 = PRIMOS, 2 = UNIX, 3 = AMIGA, 4 = MACDOS)
1 arj flags (0x01 = GARBLED_FLAG) indicates passworded file
(0x02 = RESERVED)
(0x04 = VOLUME_FLAG) indicates continued file to next
volume
(0x08 = EXTFILE_FLAG) indicates file starting position field
(0x10 = PATHSYM_FLAG) indicates path translated
("\" changed to "/")
1 method (0 = stored, 1 = compressed most ... 4 compressed fastest)
1 file type (0 = binary, 1 = 7-bit text, 2 = comment header)
(3 = directory)
1 reserved
4 date time modified
4 compressed size
4 original size (this will be different for text mode compression)
4 original file's CRC
2 filespec position in filename
2 file access mode
2 host data (currently not used)
? extra data
4 bytes for extended file position when used
(this is present when EXTFILE_FLAG is set)
? filename (null-terminated string)
? comment (null-terminated string)
4 basic header CRC
2 1st extended header size (0 if none)
? 1st extended header (not currently used)
4 1st extended header's CRC
...
? compressed file
Time stamp format:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
|<---- year-1980 --->|<- month ->|<--- day ---->|
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|<--- hour --->|<---- minute --->|<- second/2 ->|
ZIP - Extrait de AppNote.Txt
----------------------------
General Format of a ZIP file
----------------------------
Files stored in arbitrary order. Large zipfiles can span multiple
diskette media.
Overall zipfile format:
[local file header+file data] . . .
[central directory] end of central directory record
A. Local file header:
local file header signature 4 bytes (0x04034b50)
version needed to extract 2 bytes
general purpose bit flag 2 bytes
compression method 2 bytes
last mod file time 2 bytes
last mod file date 2 bytes
crc-32 4 bytes
compressed size 4 bytes
uncompressed size 4 bytes
filename length 2 bytes
extra field length 2 bytes
filename (variable size)
extra field (variable size)
B. Central directory structure:
[file header] . . . end of central dir record
File header:
central file header signature 4 bytes (0x02014b50)
version made by 2 bytes
version needed to extract 2 bytes
general purpose bit flag 2 bytes
compression method 2 bytes
last mod file time 2 bytes
last mod file date 2 bytes
crc-32 4 bytes
compressed size 4 bytes
uncompressed size 4 bytes
filename length 2 bytes
extra field length 2 bytes
file comment length 2 bytes
disk number start 2 bytes
internal file attributes 2 bytes
external file attributes 4 bytes
relative offset of local header 4 bytes
filename (variable size)
extra field (variable size)
file comment (variable size)
End of central dir record:
end of central dir signature 4 bytes (0x06054b50)
number of this disk 2 bytes
number of the disk with the
start of the central directory 2 bytes
total number of entries in
the central dir on this disk 2 bytes
total number of entries in
the central dir 2 bytes
size of the central directory 4 bytes
offset of start of central
directory with respect to
the starting disk number 4 bytes
zipfile comment length 2 bytes
zipfile comment (variable size)
C. Explanation of fields:
version made by
The upper byte indicates the host system (OS) for the
file. Software can use this information to determine
the line record format for text files etc. The current
mappings are:
0 - MS-DOS and OS/2 (F.A.T. file systems)
1 - Amiga 2 - VMS 3 - *nix 4 - VM/CMS
5 - Atari ST 6 - OS/2 1.2 extended file systems
7 - Macintosh 8 thru 255 - unused
The lower byte indicates the version number of the
software used to encode the file. The value/10
indicates the major version number, and the value
mod 10 is the minor version number.
version needed to extract
The minimum software version needed to extract the
file, mapped as above.
general purpose bit flag:
bit 0: If set, indicates that the file is encrypted.
bit 1: If the compression method used was type 6,
Imploding, then this bit, if set, indicates
an 8K sliding dictionary was used. If clear,
then a 4K sliding dictionary was used.
bit 2: If the compression method used was type 6,
Imploding, then this bit, if set, indicates
an 3 Shannon-Fano trees were used to encode the
sliding dictionary output. If clear, then 2
Shannon-Fano trees were used.
Note: Bits 1 and 2 are undefined if the compression
method is other than type 6 (Imploding).
The upper three bits are reserved and used internally
by the software when processing the zipfile. The
remaining bits are unused in version 1.0.
compression method:
(see accompanying documentation for algorithm
descriptions)
0 - The file is stored (no compression)
1 - The file is Shrunk
2 - The file is Reduced with compression factor 1
3 - The file is Reduced with compression factor 2
4 - The file is Reduced with compression factor 3
5 - The file is Reduced with compression factor 4
6 - The file is Imploded
date and time fields:
The date and time are encoded in standard MS-DOS
format.
CRC-32:
The CRC-32 algorithm was generously contributed by
David Schwaderer and can be found in his excellent
book "C Programmers Guide to NetBIOS" published by
Howard W. Sams & Co. Inc. The 'magic number' for
the CRC is 0xdebb20e3. The proper CRC pre and post
conditioning is used, meaning that the CRC register
is pre-conditioned with all ones (a starting value
of 0xffffffff) and the value is post-conditioned by
taking the one's complement of the CRC residual.
compressed size:
uncompressed size:
The size of the file compressed and uncompressed,
respectively.
filename length:
extra field length:
file comment length:
The length of the filename, extra field, and comment
fields respectively. The combined length of any
directory record and these three fields should not
generally exceed 65,535 bytes.
disk number start:
The number of the disk on which this file begins.
internal file attributes:
The lowest bit of this field indicates, if set, that
the file is apparently an ASCII or text file. If not
set, that the file apparently contains binary data.
The remaining bits are unused in version 1.0.
external file attributes:
The mapping of the external attributes is
host-system dependent (see 'version made by'). For
MS-DOS, the low order byte is the MS-DOS directory
attribute byte.
relative offset of local header:
This is the offset from the start of the first disk on
which this file appears, to where the local header should
be found.
filename:
The name of the file, with optional relative path.
The path stored should not contain a drive or
device letter, or a leading slash. All slashes
should be forward slashes '/' as opposed to
backwards slashes '\' for compatibility with Amiga
and Unix file systems etc.
extra field:
This is for future expansion. If additional information
needs to be stored in the future, it should be stored
here. Earlier versions of the software can then safely
skip this file, and find the next file or header. This
field will be 0 length in version 1.0.
In order to allow different programs and different types
of information to be stored in the 'extra' field in .ZIP
files, the following structure should be used for all
programs storing data in this field:
header1+data1 + header2+data2 . . .
Each header should consist of:
Header ID - 2 bytes
Data Size - 2 bytes
Note: all fields stored in Intel low-byte/high-byte order.
The Header ID field indicates the type of data that is in
the following data block.
Header ID's of 0 thru 31 are reserved for use by PKWARE.
The remaining ID's can be used by third party vendors for
proprietary usage.
The Data Size field indicates the size of the following
data block. Programs can use this value to skip to the
next header block, passing over any data blocks that are
not of interest.
Note: As stated in the standard PKZIP application notes,
the size of the entire .ZIP file header, including the
filename, comment, and extra field should not exceed 64K
in size.
In case two different programs should appropriate the same
Header ID value, it is strongly recommended that each
program place a unique signature of at least two bytes in
size (and preferably 4 bytes or bigger) at the start of
each data area. Every program should verify that it's
unique signature is present, in addition to the Header ID
value being correct, before assuming that it is a block of
known type.
file comment:
The comment for this file.
number of this disk:
The number of this disk, which contains central
directory end record.
number of the disk with the start of the central directory:
The number of the disk on which the central
directory starts.
total number of entries in the central dir on this disk:
The number of central directory entries on this disk.
total number of entries in the central dir:
The total number of files in the zipfile.
size of the central directory:
The size (in bytes) of the entire central directory.
offset of start of central directory with respect to
the starting disk number:
Offset of the start of the central direcory on the
disk on which the central directory starts.
zipfile comment length:
The length of the comment for this zipfile.
zipfile comment:
The comment for this zipfile.
D. General notes:
1) All fields unless otherwise noted are unsigned and stored
in Intel low-byte:high-byte, low-word:high-word order.
2) String fields are not null terminated, since the
length is given explicitly.
3) Local headers should not span disk boundries. Also, even
though the central directory can span disk boundries, no
single record in the central directory should be split
across disks.
4) The entries in the central directory may not necessarily
be in the same order that files appear in the zipfile.
--------------------------
ARC - Extrait de PkPak.Doc
--------------------------
The general format for an archive file is:
[[archive-mark + header_version + file header + file data]...] +
archive-mark + end-of-arc-mark
The archive-mark is 1 byte and is the value 1A hex. The file header
can be defined by the following 'C' structure, and is 27 bytes in size.
Note that this is a "packed" structure with fields aligned on odd-address
boundries.
typedef struct archive_file_header
{ char name[13]; /* file name */
unsigned long size; /* size of compressed file */
unsigned short date; /* file date */
unsigned short time; /* file time */
unsigned short crc; /* cyclic redundancy check */
unsigned long length; /* size of uncompressed file */
};
The name field is the null terminated file name.
The size is the number of bytes in the file data area following the
header.
The date and time are stored in the same packed format as a DOS
directory entry.
The CRC is a 16-bit CRC on the file data area based on a CRC polynomial
from the article by David Schwaderer in the April 1985 issue of PC
Technical Journal.
The length is the actual uncompressed size of the file.
The header versions are defined as follows:
Value Method Notes
----- -------- -----------------------------------------------------
0 - This is used to indicate the end of the archive.
1 Stored (obsolete) (note 1)
2 Stored The file is stored (no compression)
3 Packed The file is packed with non-repeat packing.
4 Squeezed The file is squeezed with standard Huffman squeezing.
5 crunched The file was compressed with 12-bit static Ziv-Lempel-
Welch compression without non-repeat packing.
6 crunched The file was compressed with 12-bit static Ziv-Lempel-
Welch compression with non-repeat packing.
7 crunched (internal to SEA) same as above but with different
hashing formula.
8 Crunched The file was compressed with Dynamic Ziv-Lempel-Welch
compression with non-repeat packing. The initial
ZLW code size is 9-bits with a maximum code size
of 12-bits (note 2). An adaptive reset is used
on the ZLW table when it becomes full.
9 Squashed The file was compressed with Dynamic Ziv-Lempel-Welch
compression without non-repeat packing. The initial
ZLW code size is 9-bits with a maximum code size
of 13-bits (note 3). An adaptive reset is used
on the ZLW table when it becomes full.
Note 1:
For type 1 stored files, the file header is only 23 bytes in size,
with the length field not present. In this case, the file length
is the same as the size field since the file is stored without
compression.
Note 2:
The first byte of the data area following the header is used to
indicate the maximum code size, however only a value of 12 (decimal)
is currently used or accepted by existing archive programs.
Note 3:
The algorithm used is identical to type 8 crunched files with the
exception that the maximum code size is 13 bits - i.e. an 8K entry
ZLW table. However, unlike type 8 files, the first byte following
the file header is actual data, no maximum code size is stored.
ZOO - Extrait de PIBCATZ.PAS
----------------------------
(*----------------------------------------------------------------------*)
(* Maps of ZOO file headers and entries *)
(*----------------------------------------------------------------------*)
CONST
PATHSIZE = 256 (* Max length of pathname *);
FNAMESIZE = 13 (* Size of DOS filename *);
LFNAMESIZE = 256 (* Size of long filename *);
SIZ_TEXT = 20 (* Length of header text *);
Valid_ZOO = $FDC4A7DC (* Valid ZOO tag *);
TYPE
Header_Text_Type = ARRAY[ 1 .. SIZ_TEXT ] OF CHAR;
FName_Type = ARRAY[ 1 .. FNAMESIZE ] OF CHAR;
LFname_Type = ARRAY[ 1 .. LFNAMESIZE ] OF CHAR;
Path_Type = ARRAY[ 1 .. PATHSIZE ] OF CHAR;
(* ZOO file header *)
ZOO_Header_Type = RECORD
Header_Text : Header_Text_Type (* Character text *);
ZOO_Tag : LONGINT (* Identifies archives *);
ZOO_Start : LONGINT (* Where data starts *);
ZOO_Minus : LONGINT (* Consistency check *);
ZOO_Major : CHAR (* Major version # *);
ZOO_Minor : CHAR (* Minor version # *);
END;
(* One entry in ZOO library *)
(* Fixed part of entry *)
ZOO_Fixed_Type = RECORD
(* Fixed part of entry *)
ZOO_Tag : LONGINT (* Tag -- redundancy check *);
ZOO_Type : BYTE (* Type of directory entry *);
Pack_Method : BYTE (* 0 = no packing, 1 = normal LZW *);
Next : LONGINT (* Pos'n of next directory entry *);
Offset : LONGINT (* Position of this file *);
Date : WORD (* DOS format date *);
Time : WORD (* DOS format time *);
File_CRC : WORD (* CRC of this file *);
Org_Size : LONGINT (* Original file size *);
Size_Now : LONGINT (* Compressed file size *);
Major_Ver : BYTE (* Version required to extract ... *);
Minor_Ver : BYTE (* this file (minimum) *);
Deleted : BYTE (* Will be 1 if deleted, 0 if not *);
Struc : BYTE (* File structure if any *);
Comment : LONGINT (* Points to comment; zero if none *);
Cmt_Size : WORD (* Length of comment, 0 if none *);
FName : FName_Type (* Filename *);
Var_Dir_Len : INTEGER (* Length of variable part of dir entry *);
Time_Zone : BYTE (* Time zone where file was created *);
Dir_CRC : WORD (* CRC of directory entry *);
END;
(* Variable part of entry *)
ZOO_Varying_Type = ARRAY[1..4+PATHSIZE+LFNAMESIZE] OF CHAR;
(* Varying field definitions follow *)
(* for descriptive purposes. Any or *)
(* all of these can be missing, *)
(* depending upon the setting of *)
(* Var_Dir_Len above and NamLen and *)
(* DirLen here. *)
LZH - Recherche personnelle
---------------------------
Nbr Oct Signification
--- --- -------------
1 1 ? Taille du Header - 3
1 2 ? CheckSum du Header
5 3 Algorithme utilis de la forme -lhX- o X est le numro de l'algo
4 8 Taille compresse
4 12 Taille normale
2 16 Heure
2 18 Date
1 20 Attribut du fichier
1 21 ? Niveau de Header
1 22 Longueur du nom du fichier
? 23 Nom du fichier termin par $00 (chane ASCIIZ)
Les significations prcdes d'un '?' sont de pures supputations de ma
part et n'engagent que moi, n'ayant qu'un vocabulaire Japonais trs limit
et un got pour le langage C encore plus limit 😉 .
---------------------------------------------------------------------
Je sais que la documentation des programmes ne doit pas tre diffuse
autrement que complte, mais j'espre que les diffrents auteurs ne
me tiendront pas rigueur de cet cart.
I know that the documentations of programs sould not be cut in parts
and distributed this way, but I hope that different authors will let me
do it. Archive Finder is a public domain program and I don't win any
money for writing it. The present file was made for my own use but I
thought these condensed informations might help.
If you are the author of one of the mentionned programs and you do not
want this technical stuff to be present in this file, please let me know
(real and virtual addresses are in file AF.ENG), I'll suppress it in
future releases.
Thank you.
---------------------------------------------------------------------
Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!
This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.
But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/