Stuffit – 30 Years of File Compression
stuffit.com
stuffit.com
AOL as a company with the name "AOL" started in 1991, and they started as Quantum Computer in 1989.
Cell phones started in the 1970s, so they are older, but not AOL.
OmniWeb first came out in 1995 for NextSTEP and was later released for Mac OS X. I believe it was The Omni Group's main app pre-OmniGraffle. The last stable release was in 2012, but the unstable version is still getting occasional updates.[^1]
iCab was first released in 1999 for Mac OS 7/8 as shareware. Looks like it's still getting a few updates per year, too.[^2]
[^1]: https://update.omnigroup.com/releasenotes/omniweb/OmniWeb-v6...
https://en.wikipedia.org/wiki/StuffIt
Always blew my mind that a "kid" wrote this app.
Some people just exceed our expectations. I can't achieve at that level, but I'm happy to cheer for those who can.
I started coding when I was a kid. I didn't have to seek permission from anyone, my parents didn't even know. I didn't have to obtain a license. There was no surprised clerk wondering what that kid is doing on their website, like there would have been in a physical establishment I'd need to visit for any other hobby. There was an over-13 restriction on most websites in theory (seriously, fuck COPPA), but we all knew that we should never give out our real date of birth on the internet to avoid trouble. The only places that were unavailable to me were those requiring a credit card, so a VPS was out of the question, but you could do just fine if all you had was free resources.
Mathematics is an oddball since you could study it purely with books, pencils, and paper. Programming does have an entry fee to practice, but computers became very cheap very fast in the early 1980's. By the early 1990's you could get somebody else's castoff hardware for free. By the early 2000's you could get practically any type of development tool you wanted for free. There are also plenty of stories of enthusiatic and creative people finding ways to access computers for as long as time sharing systems existed. Even if you were relatively isolated geographically and had to spend your own money on a computer, the only real cost was the initial outlay and that expense could keep someone occupied for years. (For the most part, people didn't subscribe to software or online services back then.)
Social factors also enter the picture. A kid exploring chemical reactions or disecting small animals is going to be looked upon very differently from one spending half of their waking hours programming computers. For the most part, there is nothing illegal with any of those activities. It is just that the first two usually brought to mind potentially immorall or potentially illegal activities, while the latter was viewed as harmless at worse.
He was also a big Ddial user.
#-- TMON was written by Waldemar Horwat. It was almost always used with an optional add-on, called a User Area, that was written by Darin Adler. Both of them were just kids at the time they worked on TMON. Darin Adler was a college student, and Waldemar Horwat had not yet finished high school. According to Darin Adler’s account, Horwat wrote the entire thing (in assembly language), before ever trying to assemble it.
> The source code of Keka 1.0 will not be public due some legal issues. Legal support is needed, if you can help the project, please get in contact on info@keka.io or the Project page on the official Keka website. Any help is welcome.
For that reason, these days I tend to stick with 7-Zip running through CrossOver for my archiving needs.
Mac classic resource forks, while most user friendly, were maximally power user opaque. OS X resource forks implemented as files create underlying file system messiness on non macs across network file systems but at least solved the migration and backup problem in a UNIX-like way. A slight tradeoff that's a win for interoperability.
Windows NTFS ADS, allowing any file to contain any number of other files hidden to the user was a terrible idea that never should've happened. It still works in Windows 11 and it's a giant security vulnerability that marches on because of the tyranny of "compatibility".
File metadata should be possible but it should be limited to essential OS housekeeping activities but definitely not by applications.
Faithful backup, restoration, migration, and archival needs keen attention to the preservation of platform-specific filesystem metadata and maintaining the faithful integrity of such.
Used StuffIt all the time in the classic Mac until Compact Pro came along. Compression wars!
Retvrn to https://macintoshgarden.org/sites/macintoshgarden.org/files/...
Does anyone know if that makes sense? Did the format ever change?
From Wikipedia:
"[Stuffit X] was designed to be extendable, support more compression methods, support long file names, and support Unix and Windows file attributes. StuffIt X improves over the original StuffIt format and its descendants by adding multiple compression algorithms such as PPM, and BWT to LZW-type compression. It also added a "block mode" option, error correcting "redundancy" options to protect against data loss, and several encryption options. In January 2005, JPEG compression was added as a StuffIt X compression option"
Unlike the original Stuffit format, Stuffit X never saw any significant use, since Mac OS X had switched to Zip as its default archive format.
This was like... 1999 to 2005ish, so definitely feeling my "elder millennial" status.
I used a MacSE in college (1987) and then started using them again professionally in 2008.
Mac OS X was released in 2001. The "Classic" environment was removed with the transition to x86 in 2006
Fifteen years ago was 2009. You never had the need because you came to the platform long after the transitions that made Stuffit--an absolute essential in the late eighties through the early 2000s--not relevant.
Then in 2001 OSX came out, with a new executable file format of “a specially named and structured directory in a boring UNIX file system”, and Stuffit’s reason for existing began to vanish. I’m honestly very surprised someone is still updating it now.
Mac OS X 10.3 (Panther) introduced native .zip support, and that seems to have largely taken over these days. I wonder how much of that is due to it being easier for CI systems to produce .zip archives rather than DMGs.
Unlike many people, I think the resource fork was a good idea. It structured files in a consistent way, and they were easy to examine if you had the right tools. The shortcoming is that there was not standard way (or maybe too many standard ways) to transfer files between systems intact. There was too much risk of important data being lost because the system you were transferring the data to (or a system you were transferring data through, or the software you were using was configured to ignore the resource fork) didn't recognize the resource fork or its encoding.
(It is also worth noting that a lot of file formats tend use something similar to resource forks these days. Resource forks are a bit like using zip files as a wrapper in, say, ODT and ePub files.)
Companies hate it when their teams buy new domains as it often commits them to protecting those domains for a very long time just in case.