Hard Drive Me Crazy

Though the title of this post might sound like a pornographic spam, it actually refers to a hypothetical situation.

I thought of it in response to a comment to my last post; Jon Johnson talks about what would happen with the password-changing utility if someone got a hold of your laptop.

This got me thinking. Mac OS X 10.3 “Panther” provides you with the possibility of encrypting your Home directory. This directory is unencrypted magically for you when you log in, and then encrypted again when you log out. That’s probably a simplification, but it’ll do for now.

The idea behind this feature is that if somebody steals your laptop, and you’ve logged out, they don’t automatically get access to your files, because they’re encrypted on disk. BUT if getting access to those encrypted files is as easy as runnning a startup CD/DVD utility, then the feature doesn’t help very much, does it?

My question is this: if I change the password with the utility, will it decrypt the HD when I log in with the new password, or is the HD still encrypted with the old password?

I am not about to try this at home with my laptop, which is why I called it a “hypothetical” scenario above. I would, however, be interested in the result of someone else trying it.

Any takers?

Ball and Keychain

You know that little aside I made in this post, about how helpful it can be to reset your computer password from your install CD/DVD?

Welllll…that’s not the end of the story.

I found that that same password I couldn’t remember for my computer had been embedded – separately – in my default “login” keychain. I couldn’t add anything to that keychain or change anything about it, including the password, even after I reset my computer password!

The solution was to delete the keychain and all the data associated with it, and then reset my keychains to their default state with the new password. Could have been a real pain, if I’d had a lot of entries for that keychain. I didn’t, so I was lucky.

Just an FYI.

“In a world gone mad…one man”, a.k.a. Pesky Implementation Details

Have you seen the trailer for Jerry Seinfeld’s movie Comedian? It skewers the deep, ominous voiceovers of Hollywood blockbuster trailers by showing what seems like a real movie announcer in his recording booth.

But the person behind the scenes is no laughing matter (sorry!) for the purpose I talked about in my last post: finding a comments format that had a worthwhile translator into documentation.

I was planning on spending some time trying to track down the HeaderDoc implementors, to find out the status of the project and maybe some answers to the puzzles I’ve discovered, but Wolf’s comment about Doxygen got me thinking along different lines.

In general, I think a sense of ownership really matters, and it’s easier for one person, the initial author, to own a project. Doxygen is the project of “one man,” Dimitri van Heesch, and it does seem to have momentum and a much more active mailing list.

I’m still planning on finding out more about HeaderDoc, but I’ll probably try Doxygen first.

Can I just exchange one for another? Is it just an implementation detail? I’ve found that most implementations aren’t interchangeable, and any significant project design does require knowledge of how it’s going to be implemented, even if just the bare outlines, to succeed. This is why I’m chasing after implementation first.

Will it be enough, in a world gone mad, to keep me happy?

I’ll let you know.

What’s Up, HeaderDoc?

Good code comments are an art form.

Even art needs structure, though, and I had hoped that HeaderDoc would provide me a ready-made structure for comments when they’re needed, with the promise of generating useful documentation later.

Testing the second part is what the rest of this post is about.

I downloaded HeaderDoc via its main page on Apple’s Web site, http://developer.apple.com/darwin/projects/headerdoc/, and tried to follow the instructions in the included README file to install it.

Problem: typing in the indicated sudo make realinstall gives me an error. Well, OK, first it doesn’t work because I forgot my computer’s password. Tip: your install CD/DVD can reset your password. Extremely convenient. Second, it gives me an error because I don’t have make installed. So I go to http://connect.apple.com, download Xcode 1.2, and install it. This also installs what I assumed was an older version of HeaderDoc, version 2.1. So the next time you’re trying to download all those segments of an Xcode install, blame a tiny smidgen of the bloat on HeaderDoc.

The real error is that there’s no file xml2man in the folder called xmlman/ inside the install package. There’s a makefile there, though, so I run it, run the command from above again, and it works. A post on the headerdoc-development mailing list describes this exact problem. How could a major release have been made without realizing this was a problem?

The package I downloaded is called, and all the documentation says, 8.0, but version of the headerdoc2html utility installed by “8.0” is 2.1, just like the version I installed with Xcode 1.2. I must admit, version 8.0 of anything seems a bit dodgy these days. Things tend not to get up to that version number before being renamed, re-branded, etc.

There are more things that confuse me. The documentation states that comments can be embedded in “source code and header files.” I also remember reading a message on the headerdoc-development mailing list to the same effect, though I can’t find that message again now.

But the utility only seems to accept *.h files and directories, not *.m files. This certainly implies that comments in *.m files are ignored, and that’s been my impression from the tests I’ve run. This is a bit disappointing, since there are times when you want additional comments in the source code file, and I’d rather they weren’t lost.

Also, the documentation talks about “tagless syntax,” the ability to put a HeaderDoc tag in front of a function or method without needing to include a @function or @method tag in the comment. This would be good: computers don’t mistype, unlike humans. But I didn’t find this to work with comments for Objective-C methods. If I didn’t include the @method tag, then the method didn’t show up in the documentation.

These sorts of issues give me the impression that if I use HeaderDoc syntax in my source code comments, it should be merely because I like the syntax, not because HeaderDoc at this point suits my documentation workflow.

I’d be curious to hear about other people’s experiences.

ADHOC MGD Seeks Same…

I’m going to ADHOC (nee MacHack, but the old Web page is gone now) this year, and my roommate arrangements at the hotel have fallen through.

Anybody going and interested in a roommate?

The ADHOC Web site has a Share-A-Room web page, and so does CocoaDev, and I’m on top of those, but I figured anyone brought over by Wolf’s strangely familiar post might see this weblog entry first.


WWDC from the Back, and Anthracite

So guess which one of these webloggers is me (Also see the full post. The picture pages have a lot of links to Mac webloggers.) This may be the only picture of me you get, so enjoy. I’m afraid I crashed the event, having found out about it only an hour or two beforehand.

Not pictured, but sitting to my left for most of the evening: Joe Pezzillo, founder of Metafy. The interface of his star product, Anthracite, looks really cool. Go see what it does for yourself, it’s difficult to explain. But aren’t the screenshots purty? Despite the name, somehow I don’t think it involves carbon.

Joining the Party

You may have noticed something if you regularly read the weblogs that I read:




in common.

I’m a little late to the party, both getting there and telling the world about it, but I got my umbrella-topped pink drink (or membership card, depending on your metaphor) on June 21, a little over two weeks ago.

There will be things I can’t talk about, but considering the silence round these parts, it’s not like that’s going to cut off a vital flow of information you’ve come to depend on!

I’m hoping to be able to post more here, since, after all, it’s so well-named.

Wish me luck!

High Noon: The Shaming of MoreIsBetter

An image well, a Classic application, and a pair of utility libraries walk into a bar….

Hm, not bad – the punchline is left as an exercise for the reader – but I have in mind not so much humor as some sort of confrontation or showdown:

The Find_icon library keeps one hand poised above its holster and eyes its rival, the MoreIsBetter library, standing across the dusty town square….

Who wins at high noon?

Well, let’s back up a step: what are they fighting about? A demure image well stands to one side, hoping against hope that someone will bring it the file icon it so richly deserves.

Getting a file icon can be very easy indeed, nothing to fight over: GetIconRefFromFile() works from 8.5 on, including OS X.

But if you want to support earlier than 8.5 (and I do, for reasons I won’t go into right now), you need a way to get that file icon for every kind of file system object: a file, a folder, a file with a custom icon, etc. etc.

The first library I found that solves this problem is Find_icon, by James W. Walker, available from http://jwwalker.com/pages/find_icon.html. As with the best of these kinds of libraries, it has a rich history of support and fixes.

However, its contender, MoreIsBetter, available from http://developer.apple.com/samplecode/MoreIsBetter/MoreIsBetter.html, should have left it lying in the dirt after the first shot. Why? It has an even more illustrious history, is officially supported by Apple, and has been worked on by some of the sharpest developers there. But, for finding file icons, it can’t shoot straight.

For one, it doesn’t work properly in Panther. Now, this may be because I’m using a Classic application to talk to the OS X Finder (sending an Apple event to the Finder is the generally accepted way to get a file icon). Classic applications certainly aren’t Apple’s priority any more, but I think there’s a decent chance it won’t work from OS X apps either – I would bet it just hasn’t been officially tested under Panther.

For two, when I used it under earlier OSes, I found an egregious programming error – something I caught in my first try. Isn’t anyone else testing this thing? (I’ll send in a bug report, don’t worry.)

For three, even under older OSes, the icons it retrieves are garbage images. Unusable. But it reports no error. And I don’t have time to debug it right now.

I suspect no one’s testing this because MoreIsBetter is currently listed under “Legacy Technologies”. While MoreIsBetter does support older OSes (I was able to get it to compile for 68K), it does proudly support Carbon and OS X. In fact, it provides many functions that Carbon doesn’t and that would be painful to code yourself.

So why is it abandoned under “Legacy”? I don’t know, and it’s a shame. This gunslinger shouldn’t be retired just yet.

Addendum: I’ve been looking around for Carbon resources the same way I’m gathering Cocoa resources on the Web, and MoreIsBetter is a good example of why I can’t find them: the best examples are often labeled “legacy” or merely “Macintosh”, since they date back to a time when the Toolbox APIs that preceded Carbon were all there was of Macintosh APIs. So when I do finally present my Carbon links, don’t expect them to label themselves that way.

Golfing Another Round: More Cocoa Links

Here are more links to Cocoa Web sites or pages to add to the first batch I presented a couple months ago.

The full list now has permanent home, http://umbar.com/macdev/lists/cocoa.html, on this weblog’s companion site, Umbar.com.


Cocoa Bindings simple tutorials from Apple:
I’ve seen developers talking on the mailing lists about issues when using Cocoa bindings for more complicated tasks, so don’t consider this the last word.

Harmless Cocoa, some apps, utility and UI classes, and a little font metrics tutorial: