Softlib

From Just Solve the File Format Problem
(Difference between revisions)
Jump to: navigation, search
(Version 3.0+ header addendum)
(File header)
Line 103: Line 103:
 
Byte 24-27: Original 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
+
Byte 28-29: Compression type (short integer): 0=stored with no compression, 1=[[LZW]], 2=[[LZH]]
  
 
In versions 3.0 and up was added:
 
In versions 3.0 and up was added:

Revision as of 23:22, 28 December 2013

File Format
Name Softlib
Ontology
Extension(s) .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.

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; probably to have multiple years like 1991-1998)

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; maybe indicating that there is an embedded marketing source/origin code that could differ depending on where the copy was distributed)

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.

Sample files

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox