68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.

MacBinary II file joiner

Posted by: bigmessowires on 2011-09-25 09:36:17 Here's a little Windows program I wrote to take separate resource fork and data fork files, and join them into a MacBinary II file. It can process a single file, or recursively search a directory and process all matching files. The file extensions for the resource file, data file, and MacBinary file are all configurable. The creator code of the encapsulated Mac file is set to '????'. The program tries to guess if a file is an application, and sets its type code to 'APPL'. The type code for non-applications is set to '????'. The Mac file create/modified dates are taken from the data file (if one exists), else from the resource file. Why did I write this? I have a ton of old Mac files that were split into separate data and resource files, created a long time ago when I copied a Mac CD backup to a PC. As far as I could tell, none of the standard Mac or PC file utilities will do this join operation. The Sourceforge project macbinconv is supposed to do it, but whenever I tried it I just got "Error: invalid string position!" This program requires the .NET 3.5 runtime, which you probably already have installed if you've got a recent version of Windows. C# source code for the program is included. MacBinaryFileJoiner.zip

Posted by: PowerPup on 2011-09-25 12:19:29 Heh, pretty nifty BMOW. 🙂 Just curious, I know that programmers need to be fluent in several programming languages. But what is your personal favorite?

Posted by: bigmessowires on 2011-09-25 18:14:06 For quick little data-crunching programs like this, I really like the .NET languages, either C# or C++ .NET. The GUI builder makes it a snap to create simple dialogs with buttons and text fields and other standard widgets, and the .NET foundation classes make it easy to work with files, the network, and other system resources. Unfortunately the resulting programs are dependent on the user having the .NET runtime installed, which is a big drawback for me since it's just one more hoop people need to jump through. I prefer apps that are completely stand-alone. I'm sure you could use Python or Java or something else to build a similar app just as quickly, but those would also be dependent on the user having some special runtime installed, and I don't have much experience with those languages.

1