• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

MacBinary II file joiner

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.

MacBinaryJoiner.jpg

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

 

Attachments

Heh, pretty nifty BMOW. :)

Just curious, I know that programmers need to be fluent in several programming languages. But what is your personal favorite?

 
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.

 
Back
Top