3 ms·
Why should it be another container format? To me the only reason that it should be a container instead of a monolithic file format seems to be an index. A plain
by lifthrasiir 6y ago
Why should it be another container format? To me the only reason that it should be a container instead of a monolithic file format seems to be an index. A plain text with some metadata and trailing indices (probably in octal, so that it is vaguely readable) might be more robust.
- PaulHoule 6y agoModern documents are composite documents. A Microsoft Word DOCX document is really a ZIP file and if you unzip it you will find XML files, PNG files, all sorts of things you can read with ordinary tools. Similarly a PDF file is a graph of more-or-less JSON objects which can be nested inside "filters" which support compression, encryption, etc. The organization of numerous small subfiles makes it easy to pick one piece out to work with in RAM which would be important on a small target.
- lifthrasiir 6y agoBut AMB doesn't have such resources nor filters at all. Also the file length limit of 64KB is not as small as it sounds; some implementations will have to only read one screenful a time (plus a bit of buffers) to save the working memory.
- PaulHoule 6y agoAnd neither did the "ar" file that the linker used on the original Unix. Before there was ZIP there was ARC, and before ARC came to the IBM PC, there were LBR (a "tar" kind of format) and the SQ compressor on CP/M (I don't know what possesed me to write a SQ decoder in BASIC instead of going straight to macro assembler) "Containers of containers (... of containers)" is a general architecture for file formats. The 64k limit makes it a lot easier to implement an an 8-bit computer in that you can use 16-bit pointers into one of the documents, going to 24-bit or 32-bit pointers would be a hassle but BASIC programmers might use floats which would work OK until they don't.