Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Framework for "container" files #122

Open
larsbrinkhoff opened this issue Apr 5, 2022 · 6 comments
Open

Framework for "container" files #122

larsbrinkhoff opened this issue Apr 5, 2022 · 6 comments

Comments

@larsbrinkhoff
Copy link
Owner

larsbrinkhoff commented Apr 5, 2022

Create a framework for "container" files similar to work and file formats. A "container" in this context is a file or other medium containing other files. Common operations on containers are:

  • Listing files.
  • Extracting all or a selection of files.
  • Creating a new container from a list of files.
  • Removing/adding/updating files in a container.

Currently supported container formats with ad-hoc support:

  • DECtape MACDMP format.
  • Raw magtapes (tape mark separated files).
  • ITS DUMP tapes.
  • ITS MAGDMP tapes.
  • ITS file systems on disks.
  • TENEX/TOPS-20 DUMPER tapes.
  • WAITS DART tapes.
  • TENCOM-X TITO tapes.
  • ITS archive files.
  • IPAK archives.
  • BSYS tapes (work in progress).
@larsbrinkhoff
Copy link
Owner Author

Future extension, but not an immediate goal, would be to have other tools operate on a file inside a container. E.g. disassemble a single file on a tape.

@larsbrinkhoff
Copy link
Owner Author

Pie in the sky. Generalize this to "containers in containers" to any depth.

The default top-level container would be the local host file system.

@atsampson
Copy link
Collaborator

I'd like eventually to add support for Multics tapes and archives as well (which aren't PDP-10, but are 36-bit, so the framework here would be useful).

@atsampson
Copy link
Collaborator

Also pie in the sky: provide a library to generate a container on the fly from a directory of files, so you could just attach a directory to a tape drive in an emulator and have it produce a tape automatically when read.

@larsbrinkhoff
Copy link
Owner Author

Multics is welcome here. I already diverged from 36-bitness by adding some 8-bit and 16-bit based formats. Really, any word size should work as long as it fits in a word_t (minus some tape metadata bits).

@larsbrinkhoff
Copy link
Owner Author

The idea to provide a library is interesting. More generally, various components could be packaged up as stand-alone libraries. We can quickly identify a few of those:

  • Word format.
  • Core image file format.
  • Container format.
  • Disassembler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants