Introducing Tiny Transfer! A simple BinHex archiving and serial transfer tool

[David Cook]

While working on old machines, I often find that I’m missing a utility or enabler on my SCSI emulator drive. Or, sometimes I’ll take screenshot or run a Norton speed test on that old machine that I need to bring back to my Windows PC to post to the forum. I want a quick way of transferring files without the hassle of copying a drive image over.

So, I wrote a little program called ‘Tiny Transfer’. You just plug a serial cable between the two machines and can send files back and forth.



Tiny Transfer works on the oldest Macs and operating systems, all the way up to emulators such as Basilisk II. It is a standalone application. No installers or extensions. No need for AppleTalk, servers, or routers.

As an added benefit, it can encode and decode files in BinHex format (“.hqx”), which is often needed when you obtain a file from an Internet repository. Tiny Transfer extends the BinHex format to include file dates and Finder comments. So, it preserves more of the original file information than classic BinHex does.



It is easy to use and features an informative progress window.



It does some other cool things, too. It synchronizes the clock, it allows copy and pasting of files in an emulator, and it verifies resource forks of files on encode/decode. Read the manual for details.

The application is attached ("Tiny Transfer.hqx"), along with a user manual. If you have any suggestions or questions, please let me know.

- David

P.S. Ironically, you’ll need BinHex or StuffIt to decode the attached application. After that, you won’t need BinHex anymore, as Tiny Transfer performs the same function with added speed and file info.

 

[Mk.558]

Read through the manual...I like it! Don't have a use for it at the moment, but I'll make sure to try to remember it.

How'd you get a serial transfer going at 140.32KB/sec?

 

[David Cook]

How'd you get a serial transfer going at 140.32KB/sec?

I wish! The image above is showing both the primary operations of the tool. It can send BinHex files (which the user is about to choose from the File menu) and it can convert files to/from BinHex (which the user previously did in the progress window displayed).

Or, put simply, the 140.32KB/sec was the speed of converting a file to BinHex on the disk, not sending it over the serial port.

 

[CkWeb]

This is fantastic tool, David! Thank you so much for putting this together!

Any thoughts on possibility of a .bin creation tool as well? I ask because I tend to like that slightly newer format just a bit more (but I completely get the need for a tool compatible with older file types for early Macs and OSes, so .hqx was absolutely the right first choice to go for!)

My use-case scenario is similar: to simply create self-mounting images encoded as .bin to completely ditch the need for StuffIt and it's ten million iterations! I use MacBinary with StuffIt's magic menu; I was just a little disappointed that the MacBinary encoding can only encode one file per .bin file, so the self-mounting image bundles everything in a neat volume.

 

[David Cook]

Any thoughts on possibility of a .bin creation tool as well?

Yes, good suggestion.

I have a room full of half-assembled Macs at the moment. After I catch up on the hardware projects, I'll work on "Tiny Transfer Plus":
1. Support folders
2. Better compression. Something like @bigmessowires FC8. I'm looking for something that provides decent compression but is open and simple enough that other people can support the format.
3. Multi-packet transmission. Between #2 and #3, this will double the file transfer speed.

The reason I've avoided these three features is that they require a new format/protocol.

I'll add MacBinary to the list.

- David

 

[Snial]

Very cool!

 

[CkWeb]

Thank you, David!

As much as I enjoy Magic Menu, nothing beats a dedicated tool. Plus if someone good at Applescript writes one for it, they can make Disk Copy grab a folder, create a .smi and then have the latest MacBinary app wrap it up for Christmas with just one tiny but mighty click!

Wow! Your Plus version is set to, and with the talent of others, like the FC8 developer, it will definitely redefine Classic Mac archival!

 

[mactjaap]

Super cool!

 

[rieSha.]

So, I wrote a little program called ‘Tiny Transfer’. You just plug a serial cable between the two machines and can send files back and forth.

Nice one, thank you!

 

[David Cook]

Updated Tiny Transfer attached.

1. Fixed “Missing or incomplete footer” errors when the footer happens to fall on a boundary such this it is processed in parts rather than all at once.
2. When sending via XModem, very compressible files can cause a delay before sending the next packet, because the application is focused on compressing rather than transmitting. The receiver sometimes gives up. The ideal fix would be to send a message to let the receiver know to be patient. Unfortunately, the XModem protocol does not have such a feature. A workaround is for the user to first convert the file to BinHex (where it can be compressed leisurely), and then Send it. Tiny Transfer has been improved to reduce occurrences. It now allows the receiver to impatiently nak instead of immediately cancelling. Also, it feeds larger source file chunks into the compression routine so that it can accomplish more per call, which reduces delays.
3. Now saves and restores the File Lock. Note: System 1.0 (aka 0.97) doesn’t seem to be able to fully unlock files that are locked programmatically.
4. Clears some additional Finder flags if the source file and the destination OS have different definitions of Finder flags. System 7 changed the meaning of these flags. For example, Finder’s file locked flag became the alias flag in System 7.
5. In the Edit menu, the Paste menu item is no longer enabled if the clipboard is empty.
6. The Preferences dialog had a typo, where the word “dragged” was spelled “draqged”
7. Added a visual delay to command keys to highlight the menu better on fast machines.
8. Fixed a bug in XModem where the padding length was added 0x1A times rather than 0x1A being added padding length times. This does not affect the file integrity, as the padding is ignored by BinHex. However, this fix avoids garbage from appearing at the end when sending to a terminal program.
9. Fixed a bug when detecting HFS volumes (such as an HD20 or 800KB disk) on computers with 64KB ROMs. This caused comments to not be saved/restored on HFS volumes on the Macintosh 128K and 512K.

 

[olePigeon]

@David Cook Ooo, very nice. Does it know how to handle files that end up being longer than 32 characters? I have to toggle between two different binhexing utilities because one will truncate long file names, but can only handle one file at a time; while the other can handle lots of files at a time, but craps out when a file is longer than 32 characters.

Edit: I was confused about MacBinary and BinHex. Apparently BinHex 5.0 integrated support for MacBinary.

 

[David Cook]

Hello @olePigeon

Interesting. I have a bunch of questions.

>> Does it know how to handle files that end up being longer than 32 characters?

Tiny Transfer truncates all file names to 31 characters (Inside Macintosh IV page 90) for maximum compatibility. This occurs both when getting the file name from the OS to store in an archive, and when getting the file name from the archive. It is designed to be read-compatible with archives that have longer file names (up to 255 characters) -- even though it will still truncate the extracted file name to 31 characters.

Out of curiosity, what files do you have that have names longer than 31 characters? MFS?

>> but can only handle one file at a time; while the other can handle lots of files at a time

Do you mean a .hqx file contains more than one file? Or do you drag multiple .hqx files at time?

 

[olePigeon]

Hello @olePigeon

Interesting. I have a bunch of questions.

>> Does it know how to handle files that end up being longer than 32 characters?

Tiny Transfer truncates all file names to 31 characters (Inside Macintosh IV page 90) for maximum compatibility. This occurs both when getting the file name from the OS to store in an archive, and when getting the file name from the archive. It is designed to be read-compatible with archives that have longer file names (up to 255 characters) -- even though it will still truncate the extracted file name to 31 characters.

Out of curiosity, what files do you have that have names longer than 31 characters? MFS?

>> but can only handle one file at a time; while the other can handle lots of files at a time

Do you mean a .hqx file contains more than one file? Or do you drag multiple .hqx files at time?

I don't have files longer than 31, System 7 will complain. However, I run into limits when encoding files, especially Disk Images. I use ".img" for DC6 images, and ".image" for DC4 images. So if I have a disk image of something like "More After Dark Disk 1.image" and then BinHex encode it, it'll be more than 31 characters.

By multiple files, I mean dragging (or selecting from the file menu) multiple files to encode them individually as separate .hqx files (so they're queued up and encode one after another.)

 

[David Cook]

So if I have a disk image of something like "More After Dark Disk 1.image" and then BinHex encode it, it'll be more than 31 characters.

Got it. Well, the length of the file name is truncated to 31 characters before encoding in Tiny Transfer. So, that won't be a problem.

By multiple files, I mean dragging (or selecting from the file menu) multiple files to encode them individually as separate .hqx files (so they're queued up and encode one after another.)

That's also supported. Tiny Transfer supports AppleEvents in System 7 -- and thus should be able to process multiple files at a time. Prior to System 7, CountAppFiles and GetAppFiles is handled at launch, and Multifinder 'mstr' is supported.