Softlib
Dan Tobias (Talk | contribs) |
Dan Tobias (Talk | contribs) |
||
| Line 3: | Line 3: | ||
|extensions={{ext|slb}} | |extensions={{ext|slb}} | ||
}} | }} | ||
| − | + | '''[[Softlib]]''' was a compression/archiving program used by Softdisk Publishing in the 1990s as a container format for their programs and data, but not actually released directly as a published program. Some game data files used in the Gamer's Edge product were compressed this way (with the decompression algorithm built into the game program itself), and various self-extracting installers for Softdisk products used the Softlib format for their compressed data. | |
| − | '''Softlib''' was a compression/archiving program used by Softdisk Publishing in the 1990s as a container format for their programs and data, but not actually released directly as a published program. Some game data files used in the Gamer's Edge product were compressed this way (with the decompression algorithm built into the game program itself), and various self-extracting installers for Softdisk products used the Softlib format for their compressed data. | + | |
Standalone archived files in this format might have a .SLB extension (or might not; Softlib didn't enforce particular file naming conventions), but the self-extracting version (as a .EXE file) was more commonly encountered. One distinctive feature of Softlib-archived self-installers is that when you execute them from the DOS command line with the parameter /VER added, they display version information including the version of Softlib that was used to create the archive. | Standalone archived files in this format might have a .SLB extension (or might not; Softlib didn't enforce particular file naming conventions), but the self-extracting version (as a .EXE file) was more commonly encountered. One distinctive feature of Softlib-archived self-installers is that when you execute them from the DOS command line with the parameter /VER added, they display version information including the version of Softlib that was used to create the archive. | ||
| Line 10: | Line 9: | ||
== Format == | == Format == | ||
| − | If the file is a self-extracting archive, you first need to skip the executable code; this is done by reading the first six bytes of the file, bytes 0 through 5, and then treating bytes 2 and 3 as | + | If the file is a self-extracting archive, you first need to skip the executable code; this is done by reading the first six bytes of the file, bytes 0 through 5, and then treating bytes 2 and 3 as a [[Endianness|little-endian]] unsigned integer (call it a), and bytes 4 and 5 as another unsigned integer (call it b), and calculating a + 512*(b-1) (this may require use of a long integer variable). The result is the byte offset where the file data starts. |
The data is structured like this: | The data is structured like this: | ||
Revision as of 23:09, 28 December 2013
Softlib was a compression/archiving program used by Softdisk Publishing in the 1990s as a container format for their programs and data, but not actually released directly as a published program. Some game data files used in the Gamer's Edge product were compressed this way (with the decompression algorithm built into the game program itself), and various self-extracting installers for Softdisk products used the Softlib format for their compressed data.
Standalone archived files in this format might have a .SLB extension (or might not; Softlib didn't enforce particular file naming conventions), but the self-extracting version (as a .EXE file) was more commonly encountered. One distinctive feature of Softlib-archived self-installers is that when you execute them from the DOS command line with the parameter /VER added, they display version information including the version of Softlib that was used to create the archive.
Contents |
Format
If the file is a self-extracting archive, you first need to skip the executable code; this is done by reading the first six bytes of the file, bytes 0 through 5, and then treating bytes 2 and 3 as a little-endian unsigned integer (call it a), and bytes 4 and 5 as another unsigned integer (call it b), and calculating a + 512*(b-1) (this may require use of a long integer variable). The result is the byte offset where the file data starts.
The data is structured like this:
Archive header
Bytes 0-3: The capital letters SLIB. This identifies the file as a Softlib archive.
Bytes 4-5: Major version number of Softlib needed to extract file (unsigned integer, little-endian)
Bytes 6-7: Number of files in archive (unsigned integer)
(In versions prior to 3.0, this is the end of the header, and individual files proceed starting in the next byte. In later versions, the header continues:)
Version 3.0+ header addendum
Bytes 8-14: Version of Softlib used to create archive (not necessarily same as version needed to extract it), expressed as a null-terminated string
Bytes 15-18: Revision identifier of Softlib version, as null-terminated string (distinguishes development versions between release versions)
Bytes 19-25: Version of program the archive contains, as null-terminated string
Bytes 26-29: Revision identifier of program, as null-terminated string
Bytes 30-69: Name of program contained in archive, as null-terminated string
Bytes 70-129: Name of product line that archive is part of, as null-terminated string
Bytes 130-145: Directory name that files are intended to install into, as null-terminated string
Bytes 146-154: Command line to run program, as null-terminated string
Bytes 155-163: Name of batch file to run program, as null-terminated string
Bytes 164-172: Hack name (not really sure what this is)
Bytes 173-181: Hack batch file (not really sure what this is)
Bytes 182-197: Directory product line is installed in
Bytes 198-210: Name of documentation file
Bytes 211-220: Copyright year (null-terminated string) (why they need 10 digits for that I'm not sure)
Bytes 221-260: Copyright company name
Bytes 261-280: Company phone number
Bytes 281-284: Original file size (absolute number of bytes) as unsigned long integer
Bytes 285-288: Total file size of original files if stored in hard disk with 1K blocks as unsigned long integer
Bytes 289-292: Total file size of original files if stored in hard disk with 2K blocks as unsigned long integer
Byte 293: Number of floppy disks the archive is split between (0-255) (there was a split feature for archives that didn't fit on one floppy)
Byte 294: Number of comment lines (0-255)
Byte 295: 01=Skip copyright notice
Byte 296: topcr (not sure what this meant)
Byte 297-326: From name (string) (is this program author?)
Byte 327: endstrn (not sure what this meant)
Byte 328: srcused (not sure what this meant)
Byte 329-332: splitsize (size of each part of split archive)
(in versions prior to 5.0, this is the end of the header, but in later versions it continues:)
Version 5.0+ header addendum
Byte 323-401: Comment line 1
Byte 402: node1 (not sure what this meant)
Byte 403-472: Comment line 2
Byte 473-482: Marketing source info
Then, after the headers above, there follow the files of the archive, one after another, each with this file header:
File header
Byte 0-15: Filename (may not be null terminated if all 16 characters are used)
Byte 16-19: Offset as unsigned long
Byte 20-23: Chunk length as unsigned long
Byte 24-27: Original length as unsigned long
Byte 28-29: Compression type (short integer): 0=stored with no compression, 1=LZW, 2=LZH
In versions 3.0 and up was added:
Version 3.0+ header addendum
Byte 30-33: File time (long)
Byte 34-35: CRC (unsigned short)
Byte 36-48: Directory name (string)
Byte 49: Overwrite flag
Byte 50-62: Subdirectory name (string)
Byte 63-68: Extra bytes for future use
In versions 6.0 and up was added:
Version 6.0+ header addendum
Byte 69-81: Sub-subdirectory name (string)
Byte 82-91: Extra bytes for future use
File data
Then followed the (compressed or not) file data, with "CUNK" used as a delimiter for chunks at some points.
