>> Crutch said:

Continuing the sidebar, the history of StuffIt as a format that kept changing silently under the hood with no visibility, no changes in file extension, and no backward compatibility was frustrating in the '90s and remains very frustrating for vintage hobbyists. In the '90s, the answer was to always use StuffIt 1.5.1 or (better) Compact Pro. Today, vintage files are tiny and in modern times there is generally no need to compress them. The MacBinary format has supported streaming 2-fork Mac files including type and creator info since the dawn of time. I would love to start a movement where all future Garden uploads are just .bin flies with no compression (and please, please no .sit.hqx)! Click to expand...

I'm pretty new to vintage Macs, and the prevalence of Stuffit has definitely been frustrating to me, haha. My understanding is that you can fix them and see what version they're for in ResEdit, is that correct?

>> rjkucia said:

My understanding is that you can fix them and see what version they're for in ResEdit, is that correct? Click to expand...

Depends on what you mean by fix - you can go into resedit and change the type/creator (and maybe dump the hex to see if the header is the 5.5 or 3.5 - but if you dont have the version needed it wont decompress. And you're only fixing the ability to double click on it and launch Stuffit, you can mostly always drag it on top of expander even if the type/creator is lost.

>> Crutch said:

StuffIt as a format that kept changing silently under the hood with no visibility, no changes in file extension, and no backward compatibility was frustrating in the '90s and remains very frustrating for vintage hobbyists. Click to expand...

it IS very frustrating! although i don't remember it being a problem in the 90's. MAYBE i mostly received the self extracting archives ? (.sea) and so i just didn't notice it. or was only stuffing and extracting my own files.

but today its very frustrating. partly because i don't know if the archive i got is corrupted or if i'm using the wrong version. lol


Great idea for utility! i'm not setup for it yet. but i'll def want to use this in the future once its out of closed alpha.

It looks like MacBin3 is pretty portable and opensource - https://opensource.apple.com/source/zip/zip-6/unzip/unzip/macos/source/macbin3.c.auto.html - I have it almost compiling under thinkc5 - except there is a call to `BlockMoveData` which I'm not sure where that function exists (doesnt seem to be in toolbox) - though I'm getting a bit off track and need to focus on polish for the initial release :)

>> eric said:

I don't believe it is, there are plenty of files on the garden that are only .sit or only .img/.image and work - with the caveat you have to drag them on top of stuffit expander or use shrink wrap (for disk images). They don't have the type/creator but they still work. I could be wrong (and if I am please provide an example file so I can test!) Also for instance take FloppyEMU, you can just put disk copy images on there, no resource forks and they work fine. Click to expand...

You're not wrong. I use a PC since 1991 and I have no problem dealing with Mac Garden .sit or .dsk files despite a transit through my PC. Stuffit expander works fine with .sit. Mini-vMac and Basilisk II work fine with .dsk files. FloppyEmu also deals with .dsk like a champ.

>> eric said:

It looks like MacBin3 is pretty portable and opensource - https://opensource.apple.com/source/zip/zip-6/unzip/unzip/macos/source/macbin3.c.auto.html - I have it almost compiling under thinkc5 - except there is a call to `BlockMoveData` which I'm not sure where that function exists (doesnt seem to be in toolbox) - though I'm getting a bit off track and need to focus on polish for the initial release Click to expand...

BlockMoveData() was added in the '90s ... it guarantees that the bytes being moved don't contain any code so obviates the need for instruction cache flushing etc. and improves performance on 030/040 and perhaps PPC processors. It's documented in (I think) the mid-90s version of "Inside Macintosh: Operating System Utilities" or similar. It would not be supported in THINK C 5.

You can just use BlockMove() instead.

>> Crutch said:

You can just use BlockMove() instead. Click to expand...

This worked, now have mac binary in a little sample app in thinkc 5 - I'll post it on amendhub later.

>> eric said:

What bin format would you suggest (and is there code/documentation for it) - How would bin'ing a folder work? Click to expand...

Not sure about the technical parts so I cannot answer your question, but I myself have been continuously using Stuffit for decades. Even on my modern Mac, I have it in the menu bar to encode vintage files...



I haven't had any issues with Binhex either, neither in Mini vMac or Basilisk II.

SIT is easy to create too...

Well the alpha is going quite well, will probably open beta this weekend.

Fixing/Feedback of the Alpha Testers:
Tested on a Mac Plus up to a PowerMac on OS9
Dont let users upload a file with a resource fork (will result in an unusable file)
Dont let users upload a file with a 0 byte data fork (will result in an unusable file)
Download up to 4gb files (will take a while but you can do it!)
More instructions in default state to instruct user what to do
Better errors
Better logging
UI/UX polish

Thanks to @skate323k137 @Borgmac @jokker @OneGeekArmy @jokker and everyone else for the ideas and testing.

Final few things I'd like to wrap up are
Bump the limit up on # of files listed
Ignore ._ files OSX likes to add everywhere
Easy optimizations to speed it up a bit left over from "getting it to work" phase

>> rjkucia said:

I'm pretty new to vintage Macs, and the prevalence of Stuffit has definitely been frustrating to me, haha. My understanding is that you can fix them and see what version they're for in ResEdit, is that correct? Click to expand...

As a follow up to this, I installed Stuffit 5.5 and now I no longer have any issues with the archives I was trying. My two cents would be recommending that archivers use older versions when uploading files, since 5.5 requires an '020 and System 7, but there might be reasons I'm unaware of to use the newer version.

few more updates I added in the past few days:

Can cancel uploads and downloads with command .
Allow users to upload even if the resource fork exists (some older sit files have the fork, but not required, still warn but you can proceed)
Switched to toolkit api for download - 2x faster
Adjusted buffer size - another 2x faster
Ignore files beginning with .
100 files per folder

Left to do
Check file names for unsupported characters
Help/doc/readme updates

Awesome work, Eric. This is great stuff.

Well I'm opening up Beta 1 to whoever is still here and listening :) See document in the Drive link on how to get started and firmware/app are in the zip file. Will be getting the rest of the stuff for the release ready as time permits this week.

https://github.com/erichelgeson/BlueSCSI-Toolbox#bluescsi-transfer-utility Moved to github