Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue

TidBITS Logo


When was the last time you backed up your Mac OS X machine? The solution for many people is Retrospect 5.0 - Adam looks in depth at the new release in this week's issue. Also, Matt Neuburg starts a two-part examination of Unicode and what it means to you. In the news, KeyStrokes for Mac OS X provides helpful adaptive technology for disabled Mac users wanting to use the new operating system. (And no, we're not making any of this up!)


Copyright 2002 TidBITS Electronic Publishing. All rights reserved.
Information: <> Comments: <>

This issue of TidBITS sponsored in part by:


Keyboard Accessibility for Mac OS X -- In his TidBITS series on accessibility for disabled Macintosh users, Joe Clark bemoaned the state of adaptive technology in Mac OS X. Last week's release of KeyStrokes for Mac OS X from the Dutch company Niemeijer Consult could help improve Mac OS X's position in the adaptive technology world. KeyStrokes displays a graphical keyboard on the screen; users type by positioning the cursor over letters and clicking the button of a mouse, trackball, head pointer, or other pointing device. For those who can position the cursor but can't click a button, KeyStrokes provides a system-wide "dwell-based" utility that enables clicking, double-clicking, and click-and-drag by holding the cursor motionless for a short period of time over the desired target. Text can be entered into any application in Mac OS X, even those running in Classic. U.S. and international keyboard layouts are available and the program supports Command-key combinations, dead keys (for accents), and modifier key-click combinations. KeyStrokes for Mac OS X costs $200 and includes a copy of KeyStrokes 2.2 for System 7.1 through Mac OS 9.2; volume and upgrade discounts are available. For those who want to try it first, there's a fully functional demo. [ACE]


Two Bytes of the Cherry: Unicode and Mac OS X, Part 1

by Matt Neuburg <>

If you're using Mac OS X, a massive revolution is proceeding unnoticed on your computer. No, I don't mean Unix, preemptive multitasking, or any other familiar buzzwords. I'm talking about text.

How can text be revolutionary? Text is not sexy. We take text for granted, typing it, reading it, editing it, storing it. Text is one of the main reasons most people bought computers in the first place. It's a means, a medium; it's not an end, not something explicit. The keyboard lies under our hands; strike a key and the corresponding letter appears. What could be simpler?

But the more you know about text and how it works on a computer, the more amazing it is that you can do any typing at all. There are issues of what keyboard you're using, how the physical keys map to virtual keycodes, how the virtual keycodes are represented as characters, how to draw the characters on the screen, and how store information about them in files. There are problems of languages, fonts, uppercase and lowercase, diacritics, sort order, and more.

In this article I'll focus on just one aspect of text: Unicode. Whether or not you've heard of Unicode, it affects you. Mac OS X is a Unicode system. Its native strings are Unicode strings. Many of the fonts that come with Mac OS X are Unicode fonts.

But there are problems. Mac OS X's transition to Unicode is far from complete. There are places where Unicode doesn't work, where it isn't implemented properly, where it gets in your way. Perhaps you've encountered some of these, shrugged, and moved on, never suspecting the cause. Well, from now on, perhaps you'll notice the problems a little more and shrug a little less. More important, you'll be prepared for the future, because Unicode is coming. It's heavily present on Mac OS X, and it's only going to become more so. Unicode is the future - your future. And as my favorite movie says, we are all interested in the future, since that is where we shall spend the rest of our lives.

ASCII No Questions -- To understand the future, we must start with the past.

In the beginning was writing, the printing press, books, the typewriter, and in particular a special kind of typewriter for sending information across electrical wires - the teletype. Perhaps you've seen one in an old movie, clattering out a news story or a military order. Teletype machines worked by encoding typed letters of the alphabet as electrical impulses and decoding them on the other end.

When computers started to be interactive and remotely operable, teletypes were a natural way to talk to them; and the first universal standard computer "alphabet" emerged, not without some struggle, from how teletypes worked. This was ASCII (pronounced "askey"), the American Standard Code for Information Interchange; and you can still see the teletype influence in the presence of its "control codes," so called because they helped control the teletype at the far end of the line. (For example, hitting Control-G sent a control code which made a bell ring on the remote teletype, to get the operator's attention - the ancestor of today's alert beep.)

The United States being the major economic and technological force in computing, the ASCII characters were the capital and small letters of the Roman alphabet, along with some common typewriter punctuation and the control codes. The set originally comprised 128 characters. That number is, of course, a power of 2 - no coincidence, since binary lies at the heart of computers.

When I got an Apple IIc, I was astounded to find ASCII extended by another power of 2, to embrace 256 characters. This made sense mathematically, because 256 is 8 binary bits - a byte, which was the minimum unit of memory data. This was less wasteful, but it was far from clear what to do with the extra 128 characters, which were referred to as "high ASCII" to distinguish them from the original 128 "low ASCII" characters. The problem was the computer's monitor - its screen. In those days, screen representation of text was wired into the monitor's hardware, and low ASCII was all it could display.

Flaunt Your Fonts, Watch Your Language -- When the Macintosh came along in 1984, everything changed. The Mac's entire screen displayed graphics, and the computer itself, not the monitor hardware, had the job of constructing the letters when text was to be displayed. At the time this was stunning and absolutely revolutionary. A character could be anything whatever, and for the first time, people saw all 256 characters really being used. To access high ASCII, you pressed the Option key. What you saw when you did so was amazing: A bullet! A paragraph symbol! A c-cedilla! Thus arrived the MacRoman character set to which we've all become accustomed.

Since the computer was drawing the character, you also had a choice of fonts - another revolution. After the delirium of playing with the Venice and San Francisco fonts started to wear off, users saw that this had big consequences for the representation of non-Roman languages. After all, no law tied the 256 keycodes to the 256 letters of the MacRoman character set. A different font could give you 256 more letters - as the Symbol font amply demonstrated. This, in fact, is why I switched to a Mac. In short order I was typing Greek, Devanagari (the Sanskrit syllabary), and phonetic symbols. After years of struggling with international typewriters or filling in symbols by hand, I was now my own typesetter, and in seventh heaven.

Trouble in Paradise -- Heaven, however, had its limits. Suppose I wanted to print a document. Laser printers were expensive, so I had to print in a Mac lab where the computers didn't necessarily have the same fonts I did, and thus couldn't print my document properly. The same problem arose if I wanted to give a file to a colleague or a publisher who might not have the fonts I was using, and so couldn't view my document properly.

Windows users posed yet another problem. The Windows character set was perversely different from the Mac. For example, WinLatin1 (often referred to, somewhat inaccurately, as ISO 8859-1) places the upside-down interrogative that opens a Spanish question at code 191; but that character is 192 on Mac (where 191 is the Norwegian slashed-o).

And even among Mac users, "normal" fonts came in many linguistic varieties, because the 256 characters of MacRoman do not suffice for every language that uses a variation of the Roman alphabet. Consider Turkish, for instance. MacRoman includes a Turkish dotless-i, but not a Turkish s-cedilla. So on a Turkish Mac the s-cedilla replaces the American Mac's "fl" ligature. A parallel thing happens on Windows, where (for example) Turkish s-cedilla and the Old English thorn characters occupy the same numeric spot in different language systems.

Tower of Babel -- None of this would count as problematic were it not for communications. If your computing is confined to your own office and your own printer and your own documents, you can work just fine. But cross-platform considerations introduce a new twist, and of course the rise of the Internet really brought things to a head. Suddenly people whose base systems differed were sending each other email and reading each other's Web pages. Conventions were established for coping, but these work only to the extent that people and software obey them. If you've ever received email from someone named "=?iso-8859-1?Q?St=E9phane?=," or if you've read a Web page where quotes appeared as a funny-looking capital O, you've experienced some form of the problem.

Also, since fonts don't travel across the Internet, characters that depend on a particular font may not be viewable at all. HTML can ask that certain characters should appear in a certain font on your machine when you view my page, but a fat lot of good that will do if you don't have that font.

Finally, there is a major issue I haven't mentioned yet: for some writing systems, 256 characters is nowhere near enough. An obvious example is Chinese, which requires several thousand characters.

Enter Unicode.

The Premise and the Promise -- What Unicode proposes is simple enough: increase the number of bytes used to represent each character. For example, if you use two bytes per character, you can have 65,536 characters - enough to represent the Roman alphabet plus various accents and diacritics, plus Greek, Russian, Hebrew, Arabic, Devanagari, the core symbols of various Asian languages, and many others.

What's new here isn't the codification of character codes to represent different languages; the various existing character sets already did that, albeit clumsily. Nor is it the use of a double-byte system; such systems were already in use to represent Asian characters. What's new is the grand unification into a single character set embracing all characters at once. In other words, Unicode would do away with character set variations across systems and fonts. In fact, in theory a single (huge) font could potentially contain all needed characters.

It turns out, actually, that even 65,536 symbols aren't enough, once you start taking into account specialized scholars' requirements for conventional markings and historical characters (about which the folks who set the Unicode standards have often proved not to be as well informed as they like to imagine). Therefore Unicode has recently been extended to a potential 16 further sets of 65,536 characters (called "supplementary planes"); the size of the potential character set thus approximates a million, with each character represented by at most 4 bytes. The first supplementary plane is already being populated with such things as Gothic; musical and mathematical symbols; Mycenean (Linear B); and Egyptian hieroglyphics. The evolving standard is, not surprisingly, the subject of various political, cultural, technical, and scholarly struggles.


What has all this to do with you, you ask? It's simple. As I said at the outset, if you're a Mac OS X user, Unicode is on your computer, right now. But where? In the second half of this article, I'll show you.

Retrospect 5.0 Enables Mac OS X Backups

by Adam C. Engst <>

Last week we ran out of room to write much about Dantz Development's release of Retrospect 5.0, the lack of which, for many people serious about their backups (see our "Backed Up Today?" series of articles on the topic), was the main obstacle preventing upgrades to Mac OS X.


First off, I want to explain briefly why we had to wait so long for Retrospect 5.0, and why making it compatible with Mac OS X was much harder than it would appear. In Mac OS X, Apple essentially bolted the classic Mac OS on top of a Unix operating system. Although Apple did a generally good job of making this connection invisible to users, the differences between the way the Mac OS and Unix handle files are glaring to an application like Retrospect that needs to be able to restore files exactly as it backed them up. Mac OS files have different attributes and permissions than Unix files, and Mac OS files can even have resource forks, which Unix files lack. Plus, in the Mac OS, the only type of links are aliases, whereas Unix offers several different types of links. Even case-sensitivity is different between the two.

The practical upshot of these differences was that Cocoa (and Unix) applications couldn't generally see the Mac OS attributes and resource forks, and Classic applications couldn't handle the Unix attributes, permissions, and links. The happy medium had to be a specially written Carbon application that had been coded to handle both Unix and Macintosh file information. To address this, Dantz initially released a free Retrospect Client for Mac OS X Preview that worked with a plug-in to Retrospect 4.3 under Mac OS 9 to back up Mac OS X-based machines; it was basically a hack that worked, but wasn't ideal.


Operating system support was necessary as well, and it wasn't until Mac OS X 10.1.2, released in late December of 2001, that Apple fixed all the bugs that had previously made it impossible to restore a working Mac OS X installation from a backup. Dantz immediately released a free Retrospect 5.0 Preview that ran under Mac OS X and could back up and restore properly. Dantz then spent the last few months doing final testing and packaging, leading up to last week's release of Retrospect 5.0, which can do essentially everything Retrospect users are accustomed to doing, but with Mac OS X as well as Mac OS 9 (plus Windows, though I haven't had time to test Windows-compatibility yet). Aside from this fundamental compatibility with a mixed operating system environment, there are a few welcome changes under the hood that make Retrospect all the more useful. These changes fall into two major categories: internal changes to Retrospect's backup capabilities and changes necessary for Mac OS X.


New Under the Hood -- The most interesting of Retrospect's internal changes is the elimination of a design that severely limited the utility of backing up to external hard disks with what Retrospect calls File Backup Sets. In earlier versions of Retrospect, the catalog that stores the names of the backed-up files lives in the resource fork of a File Backup Set; unfortunately, resource forks cannot grow larger than 16 MB. That effectively limited the number of files that could be stored in a File Backup Set to between 60,000 to 75,000, regardless of the size of those files. In Retrospect 5.0, when the 16 MB limit is reached, Retrospect creates a separate .cat file to hold the catalog. These two files must be stored in the same folder and may not be renamed.

With the costs of hot-swappable FireWire hard disks as low as they are, this relatively small change simplifies the use of hard disks as dedicated backup media. Retrospect's EasyScript feature, which helps you build a backup script, now gives you this option as well. For instance, you could buy three 80 GB hard disks for less than $700 total, create a File Backup Set on each one, and rotate between them for a backup system that compares extremely favorably to tape drive systems. A set of 160 GB drives at $400 each would be even more cost-effective. Don't forget about archiving for posterity (I just had reason to recover 400 MB of software from archived backups from 1995 through 1998), but it wouldn't be difficult to remove the drive mechanism from a case, swap in a new mechanism, and store the old one for safe-keeping. More elegant than buying three separate drives would be getting one of Granite Digital's FireVue Hot-Swap Drive Systems, with which you essentially buy only one $230 case plus $30 trays for drive mechanisms that you swap in and out of the case. I haven't tried one, but they sound useful.


For people working with very large files, as can happen when editing audio or video, Retrospect 5.0 can now back up files larger than 2 GB. Most people probably didn't run into that limitation before, but lots of people will be pleased to know that Retrospect 5.0 now supports all currently shipping Apple optical drives (see Dantz's Web site for a complete compatibility list). Since Apple uses drives from various manufacturers, the level of support varies slightly - with some drives, Dantz was forced to work around drive firmware errors by requiring that you use CD-R media rather than CD-RW media (the other option was to not support the drive at all). Finally, the Advanced Driver Kit is no longer required for high-capacity tape drives.


Mac OS X Changes -- Obviously, the huge change in Retrospect 5.0 is the capability both to run under Mac OS X (10.1.2 and later) and to back up Mac OS X files from Macs running Retrospect Client under Mac OS X 10.1.2 and later. This detail is important - if you back up a Mac that has both Mac OS 9 and Mac OS X installed while it's booted into Mac OS 9, Retrospect can't access Mac OS X file permissions; and although it will back up the files, restores of those files won't give you a working Mac OS X system. Likewise, although you can back up files from mounted servers without using Retrospect Client, privileges won't be saved for later restoration.

In short, if you want to back up Mac OS X files such that they can be restored properly, make sure Mac OS X is the active operating system when backing up, and if you're backing up a Mac OS X machine over the network, use Retrospect Client rather than merely mounting the server.

Retrospect Clients have been updated for Mac OS X (Retrospect 5.0 Clients under Mac OS 9 are identical to Retrospect 4.3 Clients other than the version number), and they work only over TCP/IP, not AppleTalk. One tip: if an interrupted backup causes a Mac OS X Retrospect Client to think it's in use when it's not, Command-click the Off button to stop it, then click the On button to start it again. The same trick (toggling Retrospect Client off, then on) works in Mac OS 9 as well, though a normal click on the Off button will suffice.

Dantz also updated Retrospect's interface to support Aqua, updated the default selectors that back up specific sets of files, and changed the location of various files (preferences and logs now live in Library/Preferences/Retrospect and catalog files now default to being stored in the current user's Documents folder). The Retro.Startup extension that launched Retrospect automatically for unattended backup is now called RetroRun under Mac OS X, and it's installed in Library/StartupItems. RetroRun can automatically launch Retrospect even when no user is logged in to a Mac OS X machine. A memory leak has been reported in RetroRun; I'd expect to see an update soon (unfortunately, removing RetroRun from the StartupItems folder won't help for long, since Retrospect recreates it on launch).

Retrospect 5.0 provides a "Live Restore" feature for restoring a entire Mac OS X machine. If it isn't already in a bootable state, you must first install a base Mac OS X system, upgrading as necessary to bring it up to the same version as you're restoring, then install Retrospect, and then perform the restore. I haven't yet had an opportunity to test a Live Restore, though it's an important one. Restoring can prove a little tricky with regard to Mac OS X file permissions; I recommend reading Dantz's Knowledgebase article on the topic and testing some restores in a non-critical situation.


I think it's an open question as to whether you should run Retrospect in Mac OS 9 or Mac OS X if you have the choice. Dantz says one benefit of running in Mac OS X is that Mac OS X's improved memory management makes it possible for Retrospect to back up volumes containing hundreds of thousands of files (previously, Retrospect could run out of memory scanning those files). Plus, Dantz says Retrospect runs faster as a background application in Mac OS X thanks to Mac OS X's approach to multitasking. I won't quibble with those claims, but for non-extreme situations, Retrospect running by itself on an older PowerPC-based Mac under Mac OS 9 may be a more economical and efficient approach, particularly if you have a slow 10 Mbps network that will eliminate any performance gained by using a fast Mac.

Business Model Changes -- There's no question that Dantz has been among the Mac companies that have suffered as a result of Apple's forced march to Mac OS X. The uncertainty surrounding Mac OS X slowed Mac sales to large organizations that take backup seriously and forced Dantz to expend a great deal of back-and-forth effort with Apple just to make Retrospect work properly with Mac OS X. These problems have resulted in Dantz starting to charge for telephone support and making pricing changes in the different versions of Retrospect.


There are now four different versions of Retrospect with different capabilities, aimed at different markets:


The primary advantage of ordering directly from Dantz is that you can download the software and have it immediately, but the downside is that you'll pay a bit more. Look to resellers like TidBITS sponsor Small Dog Electronics for significantly cheaper prices on Retrospect Workgroup and Retrospect Server; other retailers also seemed to have prices slightly lower than Dantz's on Retrospect Express and Retrospect Desktop as well. No resellers had Retrospect in stock yet, though that should change within a week or two.


French, German, and Japanese localized versions are scheduled for release in the second quarter of 2002. International users can buy an English version today and then upgrade to the corresponding localized product for free when it becomes available.

Initial Impressions -- I've been putting Retrospect, primarily the Server version, through its paces, and although testing backups can be a tedious process given the amounts of data that need to be moved across my 10 Mbps wired Ethernet and (even slower) AirPort networks, I've come to a few conclusions.

First, and most importantly, Retrospect 5.0 works almost exactly the same as Retrospect 4.3 did. There was no learning curve; all of the visible features work as they did in the past. Under Mac OS X, Retrospect asks for administrator passwords at appropriate times, and although its interface looks a little different to support Aqua, I haven't noticed any significant differences.

On initial launch, Retrospect offered to import settings from previous versions; it appeared to do that flawlessly, although I might try a fresh start if I were troubleshooting a problem with Retrospect, since that would seem to be a place where subtle corruption could creep in.

As it turns out, I have been doing a lot of troubleshooting in an effort to help Dantz isolate an internal consistency check error that I and several other people have experienced. I've also seen several situations where my Mac crashed while Retrospect was backing up, although I can't specifically attribute those crashes to Retrospect. Plus, TidBITS Managing Editor Jeff Carlson experienced a problem where Retrospect would back up one of his partitions correctly, but wouldn't compare it. Luckily, as has been the case with Retrospect over the years, these bugs haven't caused any data loss in backups.


This sounds somewhat dire, and although I certainly wish I hadn't experienced any problems, years of using Retrospect have taught me that it's often an electronic canary in the digital mines. For those unfamiliar with the analogy, miners used to bring a canary down into the mine shaft as an early warning system - if noxious gases caused the canary to keel over, the miners knew to get out. Because of its need to operate at the highest possible speeds with unusual storage devices, all without losing a single bit of data, it's not unusual to see Retrospect throw an error when everything else appears to work fine. A friend once told me of a story about a large company that upgraded a Cisco router to new firmware containing a bug which lost one packet in a million. The bug went unnoticed until Retrospect started reporting errors, because although one packet in a million doesn't sound like much, it adds up to a real problem when you're backing up gigabytes of data.

In the end, for many cautious users (myself included), the release of Retrospect 5.0 makes it possible to upgrade primary workstations to Mac OS X. Although a few other backup programs have appeared in recent months, including FWB's BackUp ToolKit (the same as Tri-Edre's Tri-Backup), Qdea's Synchronize Pro X, Randall Voth's Synk, CMS Peripherals' Automatic Backup System, and PSoft's iMsafe, these utilities are appropriate primarily for individual users backing up to media that can be mounted on the desktop (no tape drives). For those who need to back up multiple Macs to any media, including high-capacity tape drives, Retrospect 5.0 is the only option on the Mac that also provides archiving and preserves resource forks, HFS+ metadata, Unix permissions and group ownership, and hard-linked files.


Non-profit, non-commercial publications and Web sites may reprint or link to articles if full credit is given. Others please contact us. We do not guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies. TidBITS ISSN 1090-7017.

Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue