Modern MacBinary Tool for MacOS 26

Use the ImportFl application from the Mini vMac Extras pages:


Then you don't need to add files to disk images first in order to copy them into the VM.

I use a "swap" disk image. A .dmg image file that works like a transfer disk. Open it on macOS, drop what you got in there, unmount it, drag the .dmg into Mini vMac, extract it. As long as you don't try to open the image in two environments at once, you won't get corruption.

Mk.558 said:

I use a "swap" disk image. A .dmg image file that works like a transfer disk. Open it on macOS, drop what you got in there, unmount it, drag the .dmg into Mini vMac, extract it. As long as you don't try to open the image in two environments at once, you won't get corruption.

Click to expand...

That doesn't seem to work for me. There isn't a filesystem that the disk image can use which will be recognized by both the host macOS computer and Mini vMac. Mac OS 8.1 or later is needed to understand the HFS+ filesystem, but Mini vMac doesn't run OS versions past 7.x. Modern macOS hasn't been able to read a standard HFS volume since Catalina (10.15) and hasn't been able to write to one since Snow Leopard (10.6).

The main problem I encounter with ImportFl transfers is that it loses the file type/creator info. You need to use a tool like ResEdit or FileTyper within Mini vMac to change the imported file's metadata so it can then be opened with StuffIt Expander or whatever.

I've used a different emulator (SheepShaver) to accomplish this: dump a folder full of files into its transfer folder, then run Disk Copy within SheepShaver and create a HFS disk image from that folder, making sure to copy the image itself back to the transfer folder when done.

The UnArchiver can extract MacBinary and Stuff-It files on a modern system. In terms with disk imaging tools, there is CiderPress II. The command line versions should run fine on macOS. The GUI versions require Wine. While more Apple II oriented, it does work with HFS disk images and MacBinary files (Stuff-it isn't supported).

There is surely still the macbinary command in macOS 26? I use it regularly in Sequoia…

To expand any kind of archive, The Unarchiver is your tool of choice.

Most stuff from Macintosh Garden is stored on a disk image so you can use The Unarchiver to expand it and then drag it directly to the Mini vMac window.

If you have actual Mac data with Resource Fork, I‘d compress it with macbinary encode and then either use ImportFl or move it to a disk image with hfsutils:

(or something like that)

If your file is macbinary encoded, it will automatically be decoded by hcopy

Thanks for all the replies. The original question (and mine) was not about expanding archives... as mentioned, The Unarchiver works great for that. The difficult part is getting Mac files into Mini vMac. If you already have a StuffIt archive, then you can use ImportFl and drag it in, and StuffIt Expander will handle it from there. But what if you have a variety of apps and documents with resource forks? Then you need to archive them into a data-only container format that can be opened by Mini vMac somehow. Individually doing `macbinary encode` on dozens of files would be tedious.

I was hopeful when I saw that there was a MiniUnZp utility in the Extras section of the gryphel website, but it effectively has the same problem: all files inside the zip get unarchived to plain data files, without resource information.

The CiderPress II command-line tool looks very promising! (The GUI app didn't work; it opens and then immediately quits.) cp2 can create a new disk image, formatted as standard HFS, and you can copy files or folders into it! The resulting image can be mounted on old versions of Mac OS X, so it appears to have been generated correctly. But Mini vMac puts up a "This is not a Macintosh disk: Do you want to initialize it?" dialog when the image file is dragged to the window. The solution to that problem was to use Disk Jockey to convert the image that CiderPress II created into a raw HFS image. Once converted, cp2 can add more files to the image and it doesn't need to be converted again.

I think the following workflow is going to be a big improvement:
1. Create a standard HFS disk image using CiderPress II, e.g.: `cp2 create-disk-image NewDisk.dc42 800kb hfs`
2. Convert that image file to raw HFS using Disk Jockey. (I don't see a way for Disk Jockey to directly create a pre-formatted HFS image.)
3. Use CiderPress II to copy files/folders into the disk image: `cp2 add NEWDISK.img /Volumes/Data/StuffToXfer`
4. Mount the image in Mini vMac.

I use StuffIt Delux in Sheepshaver.
It's not always convenient, but you can always run the application and understand whether you need it on a vintage Macintosh machine or not.

thecloud said:

That doesn't seem to work for me. There isn't a filesystem that the disk image can use which will be recognized by both the host macOS computer and Mini vMac. Mac OS 8.1 or later is needed to understand the HFS+ filesystem, but Mini vMac doesn't run OS versions past 7.x. Modern macOS hasn't been able to read a standard HFS volume since Catalina (10.15) and hasn't been able to write to one since Snow Leopard (10.6).

Click to expand...

Ah I see what's the difference. I use Tiger to do most of my pre-OS X stuff, it's a bridge between modern systems and old systems. 10.5.8 was the last to write HFS, so yeah I can see that.

Your main issue is that you don't always know what you're dealing with. Is it a Stuffit 1.5.1 archive? 3.0? 4.0? 5.0? 5.5? 6.0?

Mini vMac can only deal with up to about Stuffit 4.0 files. For the others, Mac OS 9 is a good choice. Consider using Sheepshaver to perform "initial processing": decoding and extraction. Since it has, or can, have your main HDD linked, you can simply fire up Sheepshaver and copy from macOS directly, that is, if you're not using an APFS volume, which you could be. If so, then you'll probably want some kind of HFS+ partition somewhere local. Doesn't have to be very big.

Then there's the jump from Sheepshaver to Mini vMac, which is a bit awkward since Mini vMac doesn't really do networking unless you have the LToUDP option, which only works on certain setups. But since you know what you'll be dealing with, you could just drop it into a DropStuff 4.0 archive, then use ImportFI to get it into Mini vMac.

I recommend using something like Creator Changer if you use System 7 on Mini vMac. With Macintosh Drag and Drop installed, you should be able to just drag the .sit file directly on CC 2.8.4, and because you used pre-stored type & creator code profiles, you just pick one, hit OK and it auto-quits.

Wouldn't it be cool if you could make a new StuffIt archive on your Apple Silicon Mac, then import it into Mini vMac with ImportFl?

I was looking at the source to the sitPack program. one of the Mini vMac extras on the Gryphel website, and realized that Paul adapted the code to make StuffIt 1.5.1 files from the old unix sit program that was posted to Usenet back in 1988. The original code could only deal with input files that were split into .data, .rsrc, and .info segments by xbin, and it relied on specific behavior of the unix compress program. Paul's version doesn't use compress, but it does rely on all sorts of classic Mac APIs and direct 68k trap calls which don't exist anymore. So I went back to the original unix source from 1988, which I had saved at the time with the idea that it might be useful someday, and got it working. Luckily, modern macOS still has its named fork mechanism: appending /..namedfork/rsrc to a file path gives you access to the resource fork of that file.

I've also extended the code to be able to add directories recursively to the archive, but it's currently got a bug: The Unarchiver can extract the entire archive with the folder hierarchy intact, but StuffIt Expander can't. Once I track it down, I'll post the source.

I'm guessing the .info files are the raw 32 byte FinderInfo data? If so, you can grab this natively from macOS file systems by dumping the extended attribute called com.apple.FinderInfo. Easy enough to do in C. You can technically dump the resource fork this way, but its a pain in the neck.

NJRoadfan said:

I'm guessing the .info files are the raw 32 byte FinderInfo data? If so, you can grab this natively from macOS file systems by dumping the extended attribute called com.apple.FinderInfo. Easy enough to do in C. You can technically dump the resource fork this way, but its a pain in the neck.

Click to expand...

Currently I'm just reading the FinderInfo from the resource fork. Given a file named foo, the program first tries to open foo.info, and if that doesn't exist, it opens foo/..namedfork/rsrc and reads it from the header.

EDIT: The format of the .info file created by xbin is actually 128 bytes and includes both the filename and FInfo. The old 1980s-vintage C source for both xbin and sit is online here. My updated version is still in progress. I figured out the issue with folder entries (they're supposed to contain the size of all their contents, so the entry has to be rewritten at the end of processing that directory.)

Directories are now being archived correctly!



Updated source is on Github: https://github.com/thecloudexpanse/sit. If you need me to provide prebuilt binary packages, let me know.

WoW!!!
I just tried to archive their several image files.


I moved Screens.sit to Sheepshaver, and the files are immediately opened by Graphic Converter.
Of course, without junk files ".DS_Store" did not do, but these are trifles. If it is possible to add a key to delete these files or delete them by default, it would be great.

Amazing!

V.Yakob said:

Of course, without junk files ".DS_Store" did not do, but these are trifles. If it is possible to add a key to delete these files or delete them by default, it would be great.

Click to expand...

Good idea; those should probably just be skipped by default. I haven't done a lot of testing yet, so I'm sure there will be other fixes to make.