68k New application: Tiny Transfer (BinHex .hqx conversion and file transfer)

[David Cook]

Hello everyone,

For bulk file copying on older Macs, nothing beats emulated hardware such as Floppy Emu, MacSD, ZuluSCSI, and so on. However, for sending small files back and forth, swapping the micro SD card in and out can feel a bit like sneakernet.

I've written a small application that runs on all Macs from the Mac 128K all the way up to the G3, and all operating systems they support. With Tiny Transfer, you can:
1. Send files over a serial cable to another Mac or emulator. No server, AppleTalk, inits, or reboots needed. Just a standalone application.
2. Synchronize the Mac's clock
3. Convert files to/from BinHex (.hqx) format

A limitation of the classic BinHex format is that file comments and file dates are not preserved. For many files this doesn't matter. But, when you want to publicly archive something like original versions of MacsBug, then the dates and comments are part of the story they tell. Tiny Transfer appends this additional information after the main BinHex section, so the file format stays compatible with older decoding applications.

Take a couple of minutes to download Tiny Transfer (ironically the .hqx then needs to be decoded by BinHex or StuffIt) and add it to your 'Tools' folder on your standard drive images. Then, next time you find yourself needing to convert to/from BinHex or transfer a file, give it a try!

- David

 

[ClassicHasClass]

Very nice! Will source code be available?

 

[ajacocks]

Very neat application @David Cook . Have you considered adding Zmodem? The old BBS’er in me would be happy.

- Alex

 

[David Cook]

Have you considered adding Zmodem?

Yes, I strongly considered it. Zmodem definitely has higher performance than Xmodem, as well as the ability to continue an interrupted file transfer from where it left off.

The power of Zmodem is that it uses a file offset rather than arbitrary packet numbers with ack/nak. That way you can tell the sender where you left off based of the size of the file received so far.

ZMODEM replaced the packet number with the actual location in the file, indicated by a 32-bit number. This allowed it to send NAK messages that re-wound the transfer to the point of failure, regardless of how long the file might be. This same feature was also used to re-start transfers if they failed or were deliberately interrupted. In this case, the receiver would look to see how much data had been previously received and then send a NAK with that location, automatically triggering the sender to start from that point.

Macintosh files need three different chunks: the file info, the data fork, and the resource fork. If the file info header is fixed in length (such as MacBinary), then I can still calculate the offset by acting like of all three parts are back-to-back sequential data. However, the precludes altering the size of the file contents in any way (such as the compression inherent in BinHex). One solution would be to first convert the file locally into a single fork format ("temp combined and compressed.hqx") so that it can always retry sending from a known fixed file offset. However, on a floppy drive, this might not fit and it might result in slower performance than just xmodem.

Nevertheless, good recommendation.

 

[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.