Windows Vista Task Dialog

We developers are, on the whole, a lazy breed. It goes with the territory, I think. And I'm not talking about common low-grade laziness here. I'm referring to total commitment laziness: being prepared to put in an extraordinary amount of effort to avoid doing something.

The canonical test for this is to make someone perform a task that will take 8 hours of repetitive work to perform in Excel. The non-programmer will just do the work. But a natural developer will be too lazy to do the work. Instead he will spend 7.5 hours writing a program to automate the task.

And even if the task would only have taken 3 hours, a real developer will still spend 7.5 hours writing an automated version. This transcendental form of laziness - being prepared to expend more effort than necessary simply because you're too lazy to do the work - is what I'm talking about.

For the most part, it's a Good Thing: the ability to notice and avoid unnecessary work is a useful trait in an engineer. However, it has its downsides.

When Laziness Goes Bad

While laziness in the name of avoiding repetition is all well and good, a mindless preference for the path of least resistance is not so useful. Take the MessageBox API for example - if you need to get certain kinds of input from the user, MessageBox has its attractions. Particularly when you look at your options this way:

1. Devise a dialog especially for the task at hand. Prototype it. Run usability tests, focus groups, etc. Employ graphic designers to create a visual design for the dialog. Get developers to implement the dialog and the code behind it. Re-employ graphic designers to explain to the developers exactly how they failed to execute on the exquisitely-crafted design vision. Get developers to re-implement the dialog. Iterate the last couple of steps until it looks right and works, or until nobody cares any more. Ship it!
   
2. Call the MessageBox API. Ship it!
   

To the naively lazy mind, the second option looks much more appealing. The problem is it can result in a pretty crummy user experience. Here's a particularly egregious but not exactly unusual example:

If you don't see the problem, then I'm guessing you're a developer. ;-) (Hint: what exactly am I agreeing to if I click Yes at this point?)

Poor wording notwithstanding, this style of interaction is always likely to be sub par. The buttons labels bear no direct relationship to what will happen when you click on them. (I'm guessing that the first panel in this comic from usability site OK/Cancel is poking fun at this widespread poor design practice.)

Enlightened Laziness

Anyone truly committed to laziness will find this unacceptable. Every time such a dialog appears, we are making the user expend some mental effort to map between the generic Yes/No labels and the outcome. If your software gets used a lot, the sheer volume of unnecessary work this generates is unbearable. Oh! The humanity!

Clearly the efficient (i.e. lazy) solution is to provide a UI that doesn't require the user to translate Yes and No into Save and Discard. We should just make the buttons say what they mean.

While in the long run, making life easier for our users will easily balance out the initial effort required at development time, the mere presence of extra effort at any stage will surely set your lazy senses tingling. In an ideal world, we could offer the improved user experience without having to write a dialog from scratch. Wouldn't that just be heaven?

Lazy Nirvana

Enter Vista's new Task Dialog.

Just like MessageBox, the Task Dialog saves you from building a custom dialog from scratch. But it gives you the option of building a better dialog than you can with MessageBox.

It still lets you build one exactly like MessageBox if that's what you want...

OK, so it's not exactly the same. It's a slightly different icon. We've lost the redundant disabled close button. Also, notice how the grey section at the bottom has a slightly darker line at the top, which is rounded off at the edges. And more interestingly, we have a main question and a note beneath it. This lets you ask the question succinctly, and then provide a slightly more verbose explanation beneath if necessary.

But that's not terribly interesting as it still suffers from the same basic problem as the previous dialog: meaningless button labels. That's what you get if you use the basic TaskDialog API - a slight upgrade on the basic message box.

But with only a little more work we can use TaskDialogIndirect. This API offers all sorts of variations on style, including the ability to use Command. Here are the results:

There are a variety of options on offer. You can use normal buttons if you prefer. You can show a progress bar. You can add in a collapsible section to contain more detailed information for users who would like to see it without cluttering things up for everyone else. You can add radio buttons and a checkbox if you really must. And you can embed hyperlinks in any of the text fields.

Obviously you wouldn't want to switch all of these features on at once. Just pick the options that make sense for your scenario. And you'll never want to use MessageBox again!

Next-generation, high-performance processor unveiled

The prototype for a revolutionary new general-purpose computer processor, which has the potential of reaching trillions of calculations per second, has been designed and built by a team of computer scientists at The University of Texas at Austin.

The new processor, known as TRIPS (Tera-op, Reliable, Intelligently adaptive Processing System), could be used to accelerate industrial, consumer and scientific computing.

Professors Stephen Keckler, Doug Burger and Kathryn McKinley have been working on underlying technology that culminated in the TRIPS prototype for the past seven years. Their research team designed and built the hardware prototype chips and the software that runs on the chips.

"The TRIPS prototype is the first on a roadmap that will lead to ultra-powerful, flexible processors implemented in nanoscale technologies," said Burger, associate professor of computer sciences.

TRIPS is a demonstration of a new class of processing architectures called Explicit Data Graph Execution (EDGE). Unlike conventional architectures that process one instruction at a time, EDGE can process large blocks of information all at once and more efficiently.

Current "multicore" processing technologies increase speed by adding more processors, which individually may not be any faster than previous processors.

Adding processors shifts the burden of obtaining better performance to software programmers, who must assume the difficult task of rewriting their code to run well on a potentially large number of processors.

"EDGE technology offers an alternative approach when the race to multicore runs out of steam," said Keckler, associate professor of computer sciences.

Each TRIPS chip contains two processing cores, each of which can issue 16 operations per cycle with up to 1,024 instructions in flight simultaneously. Current high-performance processors are typically designed to sustain a maximum execution rate of four operations per cycle.

Though the prototype contains two 16-wide processors per chip, the research team aims to scale this up with further development.

From root kit to boot kit: Vista's code signing compromised

At the Black Hat Conference in Amsterdam, security experts from India demonstrated a special boot loader that gets around Vista's code signing mechanisms. Indian security experts Nitin and Vipin Kumar of NV labs have developed a program called the VBootkit that launches from a CD and boots Vista, making "on the fly" changes in memory and in files being read. In a demonstration, the "boot kit" managed to run with kernel privileges and issue system rights to a CMD shell when running on Vista RC2 (build 5744), even without a Microsoft signature.

Experts say that the fundamental problem that this highlights is that every stage in Vista's booting process works on blind faith that everything prior to it ran cleanly. The boot kit is therefore able to copy itself into the memory image even before Vista has booted and capture interrupt 13, which operating systems use for read access to sectors of hard drives, among other things.

As soon as the NT Boot sector loads Bootmgr.exe, VBootkit patches the security queries that ensure integrity and copies itself into an unused area of memory. Something similar is done with the subsequent boot stages of Winload.exe and NTOSKrnl.exe so that the boot kit is running in the background when the system is finally booted; at no time are Vista's new security mechanisms, which were intended to prevent unsigned code from being executed with kernel privileges, set off.

Nitin and Vipin Kumar told heise Security in an interview that this approach would also work on Vista Final (build 6000). They said that the only thing that stopped them from subsequently porting their kit to the final version of Vista was the cost. In their presentation, the experts also showed the detailed results of their analysis of Vista's booting process.

A very time-consuming debugging process using the Bochs PC emulator was required to determine the memory areas and checksums that have to be patched because they are different with every Vista build. The two Indian experts said that it took them several weeks to go through all of the individual steps in the booting process the first time. They feel that, based on analysis, VBootkit would easily be able to patch, for instance, signed drivers on the fly and get around integrity checks. And since it runs with kernel privileges, it could in principle do everything the kernel can.

For example, it might also be possible to get access to HD video content protected by DRM on the path between the data carrier and the video card. Like the attack against Cisco NAC that was also presented at the Black Hat Conference, VBootkit makes it clear that those who control hardware ultimately also control the software that runs on it. The two experts remind everyone that although Microsoft is able to raise the bar higher for boot kits by adding on additional queries and increasingly clever algorithms, the only way completely to stop unsigned program code from being executed is by using TPM hardware.