4 ms·

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

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?

deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
ksherlock 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
  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.
tornato7 3y ago
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.
- demondemidi 3y ago
  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 3y ago
    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.
    - demondemidi 3y ago
      Pristine? You mean the same home directory that contains the 80 character NTUSER files? ;)
      - DaiPlusPlus 3y ago
        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? :(
LeoPanthera 3y ago
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 3y ago
  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
  - LeoPanthera 3y ago
    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 3y ago
      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 3y ago
        It's quite plausible that the "file size" simply didn't include the resource fork.
  - EkriirkE 3y ago

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

ksherlock 3y ago

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 3y ago
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 3y ago
  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 3y ago
    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 3y ago
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.

tornato7 3y ago

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.

demondemidi 3y ago
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 3y ago
  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.
  - demondemidi 3y ago
    Pristine? You mean the same home directory that contains the 80 character NTUSER files? ;)
    - DaiPlusPlus 3y ago
      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? :(

LeoPanthera 3y ago

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 3y ago
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
- LeoPanthera 3y ago
  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 3y ago
    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 3y ago
      It's quite plausible that the "file size" simply didn't include the resource fork.
- EkriirkE 3y ago