I'm working with an old Macintosh SE and with a modern computer. I've managed to establish a communication between the two linking the USB serial of my modern computer to the modem serial port of the Macintosh, and I can send files to the Macintosh from my modern PC. For now I have tried with text files since those can be opened in the Macintosh and it seems to be working. Now, I wanna send an executable compiled in my modern PC using retro68. Unfortunately, I can't make it work, the Macintosh throws an error saying the executable is damaged.

I'm trying to understand how old mac executable files work and why they appear to be 0 sized in my modern PC. The retro68 toolchain builds a .dsk file, a .bin file, a .bin.gdb file, as well as some other 0 sized files. I tried sending the .bin and the .bin.gdb and none of them could run in the Macintosh.

Does anyone know how to proceed ?

PS : When I mount the .dsk file in my modern PC and display its content, I can see a single 0 sized file. But when I mount the .dsk in an emulator (PCE-MacPlus), it loads perfectly and I can see and run the executable it contains (Which btw is a simple HelloWorld program I wrote), also it appears in the finder to have a non zero size. I wish I could understand how these binaries work.

  • It seems like you aren't sure what kind of files Retro68 is outputting. Wouldn't that be better to ask of the Retro68 user community?
    – Brian H
    Commented Jun 22, 2022 at 15:38
  • @BrianH Indeed I don't know much about the files built by the toolchain. I posted a similar question in the retro68 user community and I didn't get answers yet. I thought maybe I could get help here.
    – CHAMSI
    Commented Jun 22, 2022 at 15:43
  • 2
    My guess would be it's outputting a MacBinary- mac.org/utilities/macbinary
    – Brian H
    Commented Jun 22, 2022 at 15:48
  • what? floppy disk is not working? Commented Jun 23, 2022 at 12:56

3 Answers 3


Each file on the Macintosh contains two separate collections of data, referred to as the resource fork and the data fork. When communications programs receive a file, all of the data they receive is placed into the data fork, but for most executable files everything of interest is in the resource fork (some programs may also store information in the data form; I think Infocom games do this, for example).

To get around this, a utility called I think Macbinary was created which can take any Macintosh file, and generate a new file whose data fork contains everything from both the resource and data forks, preceded by a header that contains information about the file type, length of each fork, etc. The same program can also take any properly-formatted data file that starts with a Macbinary header and produce from it a Macintosh file of the proper type, whose resource and data forks contain the proper information.

Generally, Macintosh programs which are stored on non-Macintosh machines and aren't in an archive format like Stuffit have been written in Macbinary format, and that utility would be needed to convert them back.

As to what you should do if you don't already have Macbinary or some similar utility on Macintosh-formatted media, I'm not quite sure. I would guess that there are utilities for modern machines which could take an image of a 1.44MB Machintosh-formatted floppy and write it out to a physical disk, but I don't know where one would find such a thing.

  • 3
    I don't think the Macintosh system ships with any utility that can take data from a file without a resource fork and store that data into a file's resource fork, but many communications programs for the Macintosh include Macbinary-style conversion utilities within them. Some may even be configurable to automatically recognize Macbinary headers when downloading a file, in which case you would want to have your dev tools produce a Macbinary file.
    – supercat
    Commented Jun 22, 2022 at 16:35
  • 5
    It's not always MacBinary. BinHex 4 was also a popular way of combining both forks into a single package.
    – Mark
    Commented Jun 23, 2022 at 1:59
  • 3
    Worth adding that this is all specific to MacOS Classic. MacOS X/OSX/macOS uses more conventional file formats. Commented Jun 23, 2022 at 8:46
  • 1
    @supercat it was implemented. I've got a whole question here on their history. It's just that even my old mac seems to be too new to explore them. They were officially supported between 1988 and 2013. Our user Raffzahn is familiar with them and considers it a rather well-known feature. Commented Jun 23, 2022 at 14:53
  • 2
    @hippietrail: I never followed the Macintosh through the PowerPC era (I barely did anything with it after I got a Windows-compatible laser printer). My recollection is that in the Inside Macintosh days, there was a file open function that accepted an argument for which fork to open, theoretically leaving open the possibility of there being many forks, but that only values of 0 or 1 were documented as supported. If named forks were a 1998 feature, that would have been long after the era I was involved with.
    – supercat
    Commented Jun 23, 2022 at 16:56

I wanted to update my post since my problem was solved, so I thought of doing so by posting an answer.

I was using two programs server/client, that I wrote myself, in order to send files from my modern PC to the macintosh. I wrote the server in C and the client using turbo Pascal 1.1. My first problem was that the client was writing all the bytes he receives to the file system (Data fork) and that wasn't the way in which binary files were supposed to be dealt with.

Thanks to supercat's answer, I have learned more about the way in which old Macs used to manage files and adapted my Pascal code to write everything it receives to the resource fork. (I had no interest in sending more text files to the Macintosh, but only binary files).

I installed a new package on my modern PC named fondu, which comes with a program 'frombin' that can unwrap macbinary files generated by the retro68 toolchain.

I finally managed to send my HelloWorld program to the Macintosh and run it successfully :

enter image description here


Before MacBinary there was the binhex or .hqx format, where a Microsoft Basic program poked some file manager settings into memory so that the resource fork as well as the data fork could be written after converting the data from hex to binary. IIRC, Dennis Brothers wrote MacTEP, one of the first programs using binhex to allow Mac System 1.x and 2.x applications to be downloaded from Compuserve and the Info-Mac archives.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .