This is an interesting thread.
I like stuffit, personally, I think it's fine, and, I agree -- the fact that the files aren't completely backward compatible is tough.
I've never seen any evidence that they are not completely
forward compatible, so what we're here is ultimately a symptom of two things:
- File compression techniques got meaningfully better during Stuffit's lifetime and the company took advantage of new techniques when releasing new software
- To add to this point: Stuffit wasn't meant for long-term historical preservation. It was a file management tool that has its roots in the specific computing environment of the '80s and '90s and most of its foibles come down to the way people interacted with it and with Macs in those decades
- Stuffit happened to be fine for some of the role it got in the early years of the Internet but most of that was because every single Mac magazine cover disc was still shipping with the newest version of the expander, and the expander was included in the OS and with most commercial software and with packs like the apple internet connection kit
- People contributing to software archives didn't necessarily prepare their files with an intent to be used where they are, and, may not have taken into account what other people have or what their workflows are like
- I can't think of any other reason why someone would put vintage mac software into a rar or .tar.gz file or why someone would have tried to image a boot CD with toast.
Those two things together mean that most vintage Mac software archives come across as ill considered overall, because, well, they are. Almost none of these projects have a single person actually setting standards, and even if there is, people aren't following them. This is even true on vtools.
Today, the only reason to use any of these tools is either:
- you have personal nostalgia for the tool
- you are using server software that is not aware of vintage Mac files
- This, specifically, is why I tend to prefer running Classic Mac OS and OS X 10.2/3/4 servers for my vintage macs and on bridge machines, and having this available is a lot of why I am running vtools.
Macintosh {Garden|Repo|GUI} et al are absolutely a case of the latter.
Ultimately, once standards are decided, someone needs to take on the work of unpacking things using the newest available versions of all these tools, and then repacking them to whatever standards are chosen based on what's appropriate for any given piece of software. e.g. Word 1.0 for the original Mac may not make sense as a zip file, but Word 2004, which only ran on OS X, might.
I suppose the other option is to write new file compression and expansion utilities for vintage Mac and modern computers, but, to be honest, I tend to think that there's no good or compelling reason to, say, need to open a stuffit 5 archive on my modern computer.
My opinions on this largely stretch out to cover other forms of this topic, i.e. CD imaging and floppy imaging, with the caveat that CD imaging should probably go toward making an ISO on a Windows computer with a tool like imgburn -- I recently found out that the "Virtual ISO utility" works on system 7 for 68k so I don't see any reason to produce CD images in any other format, if that turns out to be true.
Which, another point on this whole thing: I think some of this is going to require research and trial and error.
My recommendation, cc
@Crutch and
@olePigeon is to make a thread in the vtools forum to propose a 68kMLA/vtools standard file compression method. My current practice there is to leave files untouched but it feels like as good a place as any to start the discussion. (If you want, I can start that thread.)
The next thing after that will be to write documentation, including rationale, for why what was picked was picked, and then start converting things.
We can't enforce standards on other communities, but we can use them here!