If you’re not a developer, you can stop reading this article. You’re not supposed to know this stuff for a while yet.
As Apple has announced, Mac OS 8.5 should ship in a month or so. It’s slated to have many major new features, but two small ones are at issue here. In Mac OS 8.5, files will gain two new attributes or "flags": icon badges and custom routing. Neither is really new, but both will become available to developers.
Icon Badges — We’ve all seen icon badges on the System Folder, the Extensions folder, and so on. Icon badges aren’t even new to files – the now-defunct DiskDoubler compression program tacked a tiny DD badge onto the corner of compressed files’ icons. Without the badge, you wouldn’t have known the file was compressed, which could have caused problems had you given it to someone without DiskDoubler. And, if DiskDoubler had changed the entire file icon, you wouldn’t necessarily have known which application owned the file.
Mac OS 8.5 will offer direct support for icon badges, such that developers can apply them whenever they want. For instance, games could save player files with badges that indicate the player’s state – live, barely alive, or in the phantom zone – or a graphics program could use badges to denote common image formats, like GIF or JPEG. Icon badges aren’t a killer feature but should prove useful.
Custom Routing — We’ve also seen file routing. Drop a control panel on the System Folder, and the Finder will tell you that it needs to live in the Control Panels folder and then put it there automatically if you like. If routing wasn’t happening that control panel would end up in the top level of the System Folder.
Routing will become more widely accessible for developers, so they can more easily tell users to drop files on the System Folder and have them routed automatically to any of the standard folders. For simple installations of items like contextual menu items or shared libraries, custom routing is a good thing.
Enter MacBinary III — The problem is that existing tools for encoding files for the Internet destroy the flags that hold the icon badge and custom routing information. If you encode files with BinHex or MacBinary II (which is generally transparent, being built into most FTP programs), that action will delete icon badge or custom routing information. It won’t otherwise damage the file, but could confuse the recipient, particularly in the case of custom routing information. Imagine telling someone to drop a file on the System Folder, assuming it will land in the Preferences folder and then having it fall loose in the System Folder. In short, BinHex and MacBinary II become lossy formats.
There are workarounds for this problem using existing tools which we’ll cover when Mac OS 8.5 is released. For the moment, I want to encourage any developer whose program transfers Macintosh files on the Internet to support MacBinary III. If your application does anything with BinHex or MacBinary II now, you should be thinking about updating it to work with MacBinary III. Also, if you’re defaulting to BinHex (in an email program, for instance), you should probably switch default encoding to a format like AppleDouble that retains the new flags. The changes from MacBinary II are minor, I’m told, and several developers are providing sample source code in Pascal and C. More information is available at the page below, and there’s a mailing list developers can join to talk about the issues. To subscribe, send email to <[email protected]>, or you can read postings on the Web at the second URL below.
MacBinary III is completely backwards compatible with MacBinary II, so a MacBinary III decoder will handle any files already stored in MacBinary II. MacBinary II decoders (like recent versions of StuffIt Expander) can also decode MacBinary III files, though (as noted above) icon badges and custom routing information will be lost.
Many developers have committed to supporting MacBinary III, including Aladdin Systems, Peter Lewis (Anarchie), Jim Matthews (Fetch), Netscape Communications, and Microsoft, so MacBinary III will supplant both BinHex and MacBinary II. I won’t be sorry to see BinHex go, since MacBinary creates smaller files and FTP sites like the Info-Mac Archive are perennially low on space. MacBinary III is the wave of the future, so make sure your programs aren’t left behind in a 7-bit BinHex past.