Library v7

What it does

• Creator mode: Packs multiple C64 files (programs, data, etc.) into a single .LBR file.
• Dissolver/extractor mode: Unpacks .LBR archives back into individual files.
• It was popular in the mid-1980s C64 public domain and BBS scene for bundling files to make uploads/downloads easier on slow 300/1200 baud modems and for floppy disk distribution.

The .LBR format (C64-specific version)

• Starts with a 3-byte ASCII signature: "DWB" (exact meaning unknown, but possibly tied to an early author).
• Followed by a simple ASCII directory (human-readable, which made it easy to implement in BASIC):
  • Number of files (e.g., "9 ")
  • For each file: filename<CR>, file type (e.g., "P" for PRG)<CR>, file size in ASCII<CR>
• File data follows immediately after the directory — no block alignment, no compression.
• Does not support REL (relative) files.
• The format is very simple and C64-native (different from the more common CP/M LBR used on other 8-bit systems).

Limitations

Library V7 does not support REL files or GEOS files.  From the preserved documentation and technical descriptions of the .LBR format used by Library V7 (the C64-specific variant from 1986 by Mike Swanson):

• It explicitly does not support REL (Relative) files.
  REL files have a special structure with a side sector chain for record-based random access (like simple databases), which the simple LBR container format doesn't handle. LBR is designed only for basic sequential files (PRG, SEQ, USR without special handling).
• It also does not support GEOS files.
  GEOS uses custom file types and structures:
  • GEOS Sequential files (often marked as USR but with GEOS-specific side sectors).
  • VLIR (Variable Length Indexed Records) files, which are a GEOS-specific multi-record format similar in concept to REL but with GEOS headers, info blocks, and different interleave.
    The plain LBR format lacks the awareness or structure to preserve GEOS metadata, side sectors, or VLIR indexing properly.

Why this limitation exists

LBR was a very early, primitive archiving tool for the C64 scene (pre-dating widespread use of ARC, LHARC ports, or ZipCode on the platform). It uses a straightforward directory header with ASCII file listings and raw data concatenation—no compression, no special file type handling beyond basic ones, and no provisions for non-standard structures like REL side sectors or GEOS VLIR chains. Attempting to archive REL or GEOS files with it would likely corrupt them upon extraction (missing side sectors, wrong interleave, lost GEOS info blocks, etc.).Alternatives from the era / for compatibility

• For REL files: Use standard C64 copy tools (like Fast Copy utilities) or later archivers that explicitly support REL (e.g., some versions of ARC or dedicated REL copiers from Compute!'s Gazette / RUN magazine era).
• For GEOS files: Use GEOS-native tools like geoPack / geoMerge, or modern cross-platform utilities (DirMaster, c1541, etc.) that handle GEOS VLIR and side sectors correctly. GEOS disks often need special conversion (e.g., to .CVT format for transfer) to preserve everything.