Support compressed .boxer bundles or inner .harddisk containers.

ZIP files are essentially a small single-file read/write filesystem, with NeXT (thus Cocoa, thus macOS) supporting use of ZIP archives as the container for "file bundles", not just unpacked directories. (Ex: iWork '07 files.) It would massively reduce the overhead of maintenance (offsite backup) and poor Spotlight metadata indexing to permit zipped bundle use. This would result in a single file per application or game, not potentially thousands.

Though, yes, this would be with the trade-off of modifying a small file within that DOS environment (e.g. creating a save game) invalidating the entire .boxer bundle, but that happens far more rarely than adding a new package to the archive. Even if the .boxer overall bundle can't be sourced from ZIP, could the .harddisk / .cdrom / .floppy inner bundles be?

My library is extensive—just under a terabyte of DOS software, alone, still to be processed. A small subset of 182 games from childhood totalling 16GB are actually comprised of 25,692 individual files, or an average of 141 files per game.

Hello. Its been a few years, but I'm interested in implementing this in he current fork. Do you have documentation on whether Apple officially supports document packages in ZIP files? I can't find anything and I suspect they don't as such, but rather implementations are more like word's docx (where Word itself handles the ZIP management).

Howdy @eduo! I just tested, and it seems Apple's own iWork suite (Pages, Numbers, Keynote) still utilize this functionality. If you run file over a Pages document—I tested by writing a sentence and embedding an image—it returns:

Untitled.pages: Zip archive data, at least v2.0 to extract, compression method=store

I'm unsurprised by the lack of compression, as this is just being used to organize structured data. Extracting this, it reveals not a typical .app bundle structure, but a more data-oriented one as might be described within Apple's foundation/bundle or foundation/resources documentation or more fundamentally described as a CFBundle.

Lastly, reference: LSTypeIsPackage described as "A Boolean value indicating whether the document is distributed as a bundle."

Data/
    pasted-movie-24.heic
    pasted-movie-small-27.heic
Index/
    (a bunch of .iwa files)
Metadata/
    BuildVersionHistory.plist
    DocumentIdentifier
    Properties.plist
preview-{micro,web}.jpg
preview.jpg

"How the System Identifies Bundles and Packages" section and linked Document Packages provide some API references for "Document Packages".

Apple really do enjoy layering their technologies, and it's starting to get a touch frustrating.

---

Ha! Original reference from 1994! But alas, no direct reference to zipped bundles. It does vaguely make reference to "hides the contents of a file package" under "Other Bundles" section.

From what I can see, zipped bundles are not really a thing in MacOS and never have been. I had been looking into this and decided some time ago it was just never supported by the OS (which is why I thought it surprising to read that maybe it was).

What I can see is that zipped keynote files follow the same structure as the unzipped version so iWork moved to ZIP and redirects what used to be file reads into zip reads and then appends changes to the ZIP.

ZIP supports incremental changes, so if you have files A, B and C in file.zip, you can modify B and it will add a new entry for the new B at the end, but the original B will still be there. Using "Save As" writes the final version.

I've confirmed this by creating dummy files, adding and removing files and saving each time. No matter what you do the files only get bigger. If you "save as" the file is the right size for its current contents.

I assume this also helps supporting undo levels across sessions. Logic Pro has a similar feature.

But it does mean ZIP is not really a filesystem that can be used as such. Existing files in a ZIP can't be modified (unless the ZIP is rewritten) but it means ZIP could conceivably used as a container for read-only volumes that have been uncompressed (rather than for ISOs). I would implement the current extensions but with a Z in them: D.cdromz, A.floppyz and have them just be a bag of files.

For c.harddisk it could also be implemented (c.harddiskz or c.harddrivez), as long as the "overlay" functionality of dosbox is used, where the changes are stored in a separate path, since in a C drive there's a lot of temporary file writing that later gets removed. The overlay filesystem can be in the gamebox itself or can be in the user's home library.