StuffIt 1.5.1 for archiving, all the way!
I totally agree - I have a Basilisk slice that I use almost exclusively for unpacking all the items that should unpack, but don't.@Crutch Yeah, there really needs to be a consensus on an official archival compression format. Not only that, but it needs to be enforced.
I love this product! ROCK solid and always works.Compact Pro (.cpt) archives
I would vote for this as a must for anything done with Stuffit.StuffIt 1.5.1 for archiving, all the way!
Expander 5.5 can but told me to install Drop Stuff, which I found as a Segmented archive that requires Drop Stuff or an older Deluxe (so the archive with the segments said) to rejoin. Once I solved *that* pain in my butt: StuffIt unpacked the .cpt archive and was missing files on System 7.5. I was doing this to install SetDate to work around the 2k20 problem on my Duo, and ended up copying the files to an HFS floppy, after extracting it from a MacOS 9.2.2 machine.StuffIt Expander can expand .cpt files too.
We are stuck with the multitudes of StuffIt files all over the Garden and elsewhere …. But there is no reason to ever, ever make any more of them!
Compact Pro!I’ll admit, I’ve never seen or dealt with CPTs. What program makes them?
What grinds my gears is that people put classic Mac software in ZIP files, or some weird image format that was never used on the Mac.... past or present. I seem to recall having to find one "special" ZIP extractor to handle one of the archives there when just putting it in ANY StuffIt (even StuffIt X) would have been better.
Back in the day, Mac software was usually posted for download in StuffIt format, usually with the option of a BinHex copy (hqx). Occasionally a publisher would post stuff in MacBinary II (bin). The bigger problem I had was classic MacOS's very rigid enforcement of filetype/creator. Applications literally wouldn't let you select a generic binary blob to extract until you set the correct type.
For a single file, compression is of course not really necessary these days, but if it's a folder or multiple items, it's a convenient way to combine into a single file for encoding (which is still a necessity for pre-osx).
I think it's amusing when new uploads are still compressed for some reason. I've been doing all of my preservation uploads in the .dsk format with a system folder installed. That provides direct compatibility to all 3 emulators. From there if someone wants to extract just the software it's as simple as writing the floppy with a Greaseweazle / Flux Engine or sending it to a Floppy Emu / Scsi2SD.
We're talking about rounding errors in storage space using an entire 800k for a .dsk image versus creating a .sit that is 200k with the amount of hard drive / cloud space we have in 2021.
Obviously original media should be archived as it is, 800k or otherwise, but if a disk image needs to be made for something, if it can run on something pre-SE, it should be on 800k. And if it's intended for pre-Plus, it should be on a 400k image!I've actually found it interesting how often the disk images I've encountered are for 800K.
I’ve been working with a lot of 1985 programs lately and it’s interesting how many programs have weird “poor” coding and only work on certain System versions.Obviously original media should be archived as it is, 800k or otherwise, but if a disk image needs to be made for something, if it can run on something pre-SE, it should be on 800k. And if it's intended for pre-Plus, it should be on a 400k image!
And yet some programs were so well programmed, that they work all the way through 9, or even Classic Mode!I’ve been working with a lot of 1985 programs lately and it’s interesting how many programs have weird “poor” coding and only work on certain System versions.