[DaiPlusPlus]

On a related note, I'm getting flashbacks to being on the web in the late-1990s, back when "Downloads!" was a reason to visit a particular website; and noticing that Windows users like myself could just download-and-run an .exe file, while the same downloads for Mactintosh users would be a BinHex file that'd also be much larger than the Windows equivalent - and this wasn't over FTP or Telnet, but an in-browser HTTP download, just like today.

Can anyone explain why BinHex remained "popular" in online Mac communities through to the early 2000s? Why couldn't Macs download "real" binary files back then?

[ksherlock]

Classic Macintosh files were basically 2 separate files with the same name (data fork and resource fork). Additionally, there was important meta data (Finder Info, most importantly the file type, creator type). Since other file systems couldn't handle forks or finder info, it had to be encapsulated in some other format like binhex, macbinary, applesingle, or stuffit. The other 3 were binary so they would have been smaller. Why not them... shrug

[ksherlock]

I wasn't a macintosh user back in the day but for the file archives I frequented (apple II), sometimes files were in BINSCII which was a similar text encoding. The advantage being that they could be emailed inline, posted to usenet, didn't require an 8-bit connection (important back in the 80s), and could be transferred by screen scraping if there wasn't a better alternative.

[devilbunny]

So this is really random, but Kermit actually could route around your 7-bit issues. Everyone remembers it as a godawful protocol choice, because terminal programs usually implemented the most basic version of the protocol, but if configured correctly it was on par with or better than Zmodem.

[jasonwatkinspdx]

Kermit was still useful into the 90s. I had a brief gig helping a friends dad set up an ecom store. Their payment processor got nightly batches of authorizations and captures by model. We were having issues getting our machine to talk with their machine, and surprisingly enough I was able to get an actual engineer on the phone. We used kermit to debug the modem handshake interactively while we conversed, figuring out the magic Hayes incantation to get them happy.

A very different world than today.

[bradknowles]

What I saw most of the time was a file that was compressed with StuffIt, and then encoded with BinHex. They were usually about inverse in terms of efficiency, so what you saved with StuffIt you would then turn around and lose with BinHex. But the resulting file was roughly the same size as the original file set.

[LeoPanthera]

The most common Macintosh archive format was (eventually) StuffIt, but StuffIt Expander couldn't open a .sit file which was missing its resource fork, and when you downloaded a file from the internet, it only came with a data fork.

So a common hack was to binhex the .sit file. Binhex was originally designed to make files 7-bit clean, but had the side effect that it bundled the resource fork and the data fork together.

Later versions of StuffIt could open .sit files which lacked the resource fork just fine, but by then .zip was starting to become more common.

[amatecha]

I could be remembering wrong, but didn't later versions of stuffit compress to a .sit file that had no resource fork, so it would stay fully-intact on any filesystem? I may be imagining that, but I remember hitting a certain version where "copying to Windows" would no longer ruin my .sit files... haha

[EkriirkE]

I don't remember there ever being a resource fork, but I Think around v4 it started allowing you to drag-n-drop any file to decompress, ignoring the missing/required finder info from previous versions

[LeoPanthera]

It's been a long time, but I don't think that's exactly true. The resource fork simply became optional, assisted by later versions of MacOS, which let applications open files which didn't have one.

[amatecha]

Ahh hmm OK, I'll have to check into this some time. I feel like the filesize would stay the same (suggesting no loss of data), but it's totally possible I'm misremembering considering how long it has been, hahah :)

[LeoPanthera]

It's quite plausible that the "file size" simply didn't include the resource fork.

[tornato7]

Funny because today I find the install process for Mac much simpler. Most installs are "drag this .app file to your Applications folder", meanwhile on Windows you download an installer that downloads another installer that does who-knows-what to your system and leaves ambiguously-named files and registry modifications all over the place.

[vbezhenar]

There are plenty of portable windows applications (distributed as a zipped directory) and there are plenty of pkg macOS installers.

I don't really understand why macOS users like this "simple" installation, because when you "uninstall" the app, it leaves all the trash in your system without a chance to clean up. And implying that macOS application somehow will not do "who-knows-what" to your system is just wrong. Docker Desktop is "simple", yet the first thing it does after launch is installing "who-knows-what".

[wruza]

Windows uninstallers also leave all the trash in %AppData%. There’s no generic way to clean all the folders that a program decided to create. Only some uninstallers ask if you want to delete settings and caches.

Given that, dragging a ready-to-run file (folder) to /Apps symlink is much more convenient than “setting up your system for preparation of initializing of downloading of the installation process starter manager, please wait and press next sometimes”.

[TheCleric]

That's definitely true for more complex apps, but the fact that you can have the executable and all it's resources in one `.app` file is so much simpler and easier for the everyday user. (Yes I know it's a folder that the OS treats as an application, but to a user it looks like one file)

I go back and forth between Windows/Mac/Linux on the daily (right tool for the right job) and each has some strengths. App packaging is far and away one of Mac's current strengths.

I maintained Nativefier (a now defunct open source project that would package web sites as Electron apps) and the ease of packaging an app was Mac > Windows > Linux.

[steve1977]

If the installer on Windows is properly done, you actually know exactly what it does to your system (including registry modifications). This includes the ability to remove the application completely.

Whereas on macOS, installation is trivial, but then the application sets up stuff upon first run and that is really intransparent then, with no way of properly uninstalling the app unless there is a dedicated uninstaller.

[Clamchop]

There are plenty of inscrutable installers for macOS software. DRM-riddled bullshit and enterprise crapware are a disease.

But yeah, the simple case is quite nice.

[demondemidi]

The one annoying thing macOS apps do is pollute /Library. Even apps that don’t explicitly write to this area end up with dozens of permafiles. Tons of stuff is spewed in there when you install an application that actually uses it. It’s like a directory version of a registry kitchen sink.

[DaiPlusPlus]

Spare a thought for us Windows users - we went from our pristine and oddly beautiful home directories in Windows 7, where everything was neatly squared-away to either AppData\Roaming or AppData\Local - to our post-Electron, lazily-ported software world where my home directory now has no-less than twenty Unix-style dot-directories littering my %USERPROFILE%

Incidentally, the worst offender is Microsoft themselves: it all got worse with .nuget, .vs, .azcopy, .azdata, .azure, .azuredatastudio, .dotnet, etc. I just don't understand it.

[pezezin]

We Linux users suffer it. Supposedly, nowadays applications should store their files under ~/.config, ~/.local and ~/.cache, but you still find a million applications that create their own folders without following any standards. But at least file browsers hide those folders by default...

[DaiPlusPlus]

I'd have thought you could easily enable some fs-jail that maps any-and-every request matching /~/..+/i wherever you want?

[pezezin]

I had never heard of it. Maybe it is possible, but I am too lazy to try it...

[winterplace]

Do you have a link to documentation for that?

[pimlottc]

It's in the XDG Base Directory Specification [0] maintained by freedesktop.org [1] (formerly X Desktop Group)

0: https://specifications.freedesktop.org/basedir-spec/basedir-...

1: https://en.wikipedia.org/wiki/Freedesktop.org

[demondemidi]

Pristine? You mean the same home directory that contains the 80 character NTUSER files? ;)

[DaiPlusPlus]

Or the back-compat symlinks for NetHood, Start, Recent, SendTo, ah yes. I had a post-install VBScript that cleaned those out.

My current sad-thing I’m unhappy about is how the “My Documents” folder ended up being a second AppData folder, with lots of software storing settings, templates, project files, etc in that dir instead of AppData.

Windows absolutely needs application-silos to protect users from lazy apps. I hate to say it, but Apple was 100% right to make iPhone OS a file-system-free OS - we can’t do that on desktop, but gosh-darn-it, why is software so terrible? :(

[wruza]

My solution is to create another folder like “~/Documents/Projects” (because I have no free-standing documents really) and use it as “my” dir. All other paths are known to apps and will be abused.