Crash Vista in 10 seconds?

According to InformationWeek, it is possible to crash Vista in 10 seconds. To do this, you hold down the Windows key and the letter ‘e‘ in Windows Explorer for 10 seconds. This opens up numerous Windows Explorer windows, and, according to the report, after about 10 seconds Vista locks up.

Reports vary on the result. Some people claim Windows Explorer crashes and restarts fairly quickly, others say they just get lots of open Windows Explorer windows and everything continues to function. We tried it ourselves on a friend’s boss’s computer (the boss wasn’t in yet, and everyone else in the company uses a Mac) and we got the following: lots of windows opened, then a dialog popped up saying that Windows Explorer had stopped working, and that “Windows is collecting more information about the problem. This might take several minutes”. The machine then seemed to lock up pretty hard. Some time in the next 30 minutes it appears the machine recovered. So it’s not quite a crash, but it certainly is an easy way to break an important bit of software with a two finger keystroke.

I am not suggesting the Mac doesn’t have a similarly trivial way to break it (though I’d love for someone to point out a two finger keystroke that can break OS X in 10 seconds – and holding down the power button doesn’t count). To be fair though, I needed to try and reproduce this on the Mac.

The Finder

The Mac equivalent of Windows Explorer is the Finder. And the Mac equivalent of Windows-E to open new Finder windows is Command-N.

So, I held down Command-N. One new Finder window opened. That was it. It seems that Command-N doesn’t auto-repeat in the Finder as Windows-E does in Windows Explorer. So, of course, my first reaction was along the lines of “In your face Microsoft! Your engineers suck dog’s balls!”.

TextEdit

I spoke too soon. Lucky I didn’t blog about it! :-)

A good friend of mine noticed that taking the application TextEdit (the Mac default text editor application), and doing Command-N (which opens new TextEdit windows) actually does auto repeat! Holding that key combination down for 10 seconds fills your screen with TextEdit windows.

Granted, TextEdit doesn’t crash. Nor does OS X. In fact, you can use Exposé and look at all the windows on screen at once (as shown here). Pretty cool!

But it seems very odd that Apple would let a menu item like this auto-repeat. Why would anyone want to do this? And why on TextEdit but not the Finder?

Carbon versus Cocoa?

My friend had a theory. The Finder is a Carbon application. TextEdit is a Cocoa application. Could this have something to do with it?

A quick test shows that BBEdit, a Carbon application, also doesn’t auto-repeat. Safari, a Cocoa application, does. Is this what is going on here?

Well, this is pretty close to the truth it seems.

When you create an interface in OS X’s Interface Builder, you can choose to build a Cocoa application or a Carbon application. If you choose a Cocoa application, the keyboard equivalents for menu bar items will auto-repeat, and Interface builder doesn’t appear to have an option to turn off this behaviour. Hence, TextEdit and Safari auto-repeat when you hold down Command-N.

However, when you create a Carbon application, keyboard equivalents by default don’t auto-repeat. There is however an option to set auto-repeat on a keyboard equivalent for a menu item (see picture to the right). As the default is not to repeat, this is probably why most Carbon applications won’t show the auto-repeat behaviour (apparently iTunes does on some menu items, and is Carbon I believe).

Question is, should this be the default in Cocoa? To me it seems an odd choice – there doesn’t seem to be many functions where I would want auto-repeat on a menu item. It would be dangerous in deleting items in an application, for example, if after deleting one item it went to the next item.

The documentation for NSMenuItem doesn’t appear to have any easy way to set or un-set auto-repeat on menu items either. So I suspect a bit of hacking is required to turn the auto-repeat off for Cocoa applications.

So there is a difference between the default way Cocoa and Carbon applications work. And the fact that the Finder doesn’t behave like Windows Explorer (I don’t mean the crash part) would appear to be purely by accident not design. Interestingly, the auto-repeat feature may be a quick way to determine if an application is a Cocoa or Carbon application, though obviously not a fool-proof way. There are claims that the Finder in Leopard is Cocoa now – I suspect it isn’t, and if someone wants to try Command-N on it, I think it will behave the same as the Finder in Tiger (I don’t have Leopard, so I can’t try it. And if I did have it I’d be under an NDA I guess, so I couldn’t talk about it).

I really like my applications to behave consistently, so this disturbs me a little. Though most applications these days are Cocoa, I think the Carbon default behaviour is better than the Cocoa default behaviour. Personally, I’d like to see Cocoa change to be consistent, with an option to turn on auto-repeat for menu items that really need it.