Sending an executable to a Macintosh SE using serial port

[chamsi68]

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. I'm trying to understand how old mac executable files work and why they appear to be 0 sized in my modern PC. Using the retro68 toolchain, I get 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, also it appears in the finder to have a non zero size. I wish I could understand how these old mac binaries work.

[ryandesign]

Macintosh files have two forks: a data fork (this is what every other operating system considers a file to be) and a resource fork.

68K Mac applications, extensions, control panels, and any other kind of compiled code files are contained entirely within the resource fork; their data forks are empty; that's why if you put such a file onto a non-Mac disk it will appear to be (and will actually be) 0 bytes—transporting the file to a non-Mac filesystem loses the resource fork and effectively destroys the file.

That's why Retro68 packages your application in another format that can survive being on a non-Mac filesystem: the MacBinary format. That's the .bin file. It's a concatenation of the data fork and resource fork and some other data into a single data fork file. You can store that file on any filesystem and you can send it over the serial connection to your Mac SE.

Your Mac SE can't run a MacBinary file directly, of course; you'll first need to decode it from MacBinary back to a real two-fork Macintosh file. StuffIt Expander can do that, as can other standalone utilities like MacBinary II+.

There's no need to do this transferring and decoding manually; Retro68's LaunchAPPL does it for you.

The .bin.gdb file is a GNU debugger file, created by the GNU compiler upon which Retro68 is based. Theoretically one could use such a file to aid in debugging a program using the GNU debugger, however that capability has not yet materialized for Retro68.

The .dsk file is a floppy disk image, suitable for opening into an emulator that supports reading floppy disks, like Mini vMac. Theoretically such an image could also be written to a real floppy disk and then put into a vintage Mac, however it's almost certainly not the exact size of a floppy disk, and possibly larger than a floppy disk, and on your PC you would only be able to write 1.44MB floppies which would only work in a Mac with an FDHD or SuperDrive floppy drive, which the original Mac SE did not have, though later SEs were sold with that drive and it was available as an upgrade kit.

[chamsi68]

Thank you for your answer. I have asked my question in Retrocomputingstackexchange and got help from the community. motorola 68000 - Sending an executable to an old Macintosh SE using serial port - Retrocomputing Stack Exchange <https://retrocomputing.stackexchange.com/questions/24705/sending-an-executable-to-an-old-macintosh-se-using-serial-port/24731#24731> I managed to solve my problem. Le mar. 20 sept. 2022 à 18:00, Ryan Schmidt ***@***.***> a écrit :

…

Macintosh files have two forks: a data fork (this is what every other operating system considers a file to be) and a resource fork. 68K Mac applications, extensions, control panels, and any other kind of compiled code files are contained entirely within the resource fork; their data forks are empty; that's why if you put such a file onto a non-Mac disk it will appear to be (and will actually be) 0 bytes—transporting the file to a non-Mac filesystem loses the resource fork and effectively destroys the file. That's why Retro68 packages your application in another format that can survive being on a non-Mac filesystem: the MacBinary format. That's the .bin file. It's a concatenation of the data fork and resource fork and some other data into a single data fork file. You can store that file on any filesystem and you can send it over the serial connection to your Mac SE. Your Mac SE can't run a MacBinary file directly, of course; you'll first need to decode it from MacBinary back to a real two-fork Macintosh file. StuffIt Expander can do that, as can other standalone utilities like MacBinary II+ <https://www.gryphel.com/c/sw/archive/macbinii/>. There's no need to do this transferring and decoding manually; Retro68's LaunchAPPL does it for you. The .bin.gdb file is a GNU debugger file, created by the GNU compiler upon which Retro68 is based. Theoretically one could use such a file to aid in debugging a program using the GNU debugger, however that capability has not yet materialized for Retro68. The .dsk file is a floppy disk image, suitable for opening into an emulator that supports reading floppy disks, like Mini vMac. Theoretically such an image could also be written to a real floppy disk and then put into a vintage Mac, however it's almost certainly not the exact size of a floppy disk, and possibly larger than a floppy disk, and on your PC you would only be able to write 1.44MB floppies which would only work in a Mac with an FDHD or SuperDrive floppy drive, which the original Mac SE did not have, though later SEs were sold with that drive and it was available as an upgrade kit. — Reply to this email directly, view it on GitHub <#155 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZX5QUNELIIFQWDXJBBPHSDV7HNTPANCNFSM5ZPUEEPQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>