Why do we need a new API?
Before talking about what Vista's new features bring to the table, it's
helpful to understand how and why the Windows of today works the way it
does and why we'd want to change things. The background is both
lengthy and important; you may wish to jump ahead to the next page if
you are quite familiar with both the history of the GDI and User APIs.
Windows has been around a long time. The current API—Win32 (and its near-identical 64-bit equivalent, Win64)—have been with us since Windows NT 3.1, launched in 1993. Its history is older still; Win32's design was largely based on that of Win16, due to the phenomenal success of the Windows 3.0 product line. Win32, though much larger and more expansive, took many concepts from Win16 to allow developers to more easily migrate to the new platform. With the release of Windows 95, Win32 became the dominant API, the status it has had ever since.
For those new to the concept, an Application Programming Interface (API) is a contract describing how one program can interact with another program in order to use the functionality of that other program. The Win32 API provides the information that programs need in order to interact with the Windows OS. The Windows OS provides all sorts of functionality—manipulating files, drawing objects on screen, communicating on networks, and so on—and the Win32 API describes all the functions and data structures needed by applications to use these capabilities. So, for example, there are functions for opening and reading files, functions for drawing lines and pictures, and functions for using network resources.
Graphics Device Interface
Win16 had two components of particular significance, one named "GDI" and the other called "User." Graphics Device Interface was the API used for drawing shapes and text onto the screen or a printer. The API is entirely bitmap-based; each program has its own bitmap "canvas" onto which it draws its shapes and text. Though the API has functions for drawing lines and bezier curves, these get immediately rasterized; though you can transform (scale, shear, translate) the things you've drawn, these operations only act on the bitmaps, and so tend to lose quality.
GDI's bitmapped nature causes all sorts of issues. One that will be a problem, "RSN," is that it's essentially pixel-oriented. Programs will draw a line that is, say, two pixels wide, or text that's ten pixels tall. In times gone by that didn't matter. Dots were about the same size on any screen you used—about 1/96". But that's not the case today; laptop LCDs will often have dots around 1/120" in size, and the very highest-end LCDs have dots measuring just 1/200". If you use your old pixel-based measurements on a screen like that everything looks tiny, only a quarter of the size you expected it to be. Though one can work around this and perform appropriate scaling, most applications don't because their developers would have to perform all the corrections by hand. So instead, if you use high resolutions, you'd better get used to tiny graphics. This problem doesn't just face rich people with fancy monitors; similar issues are faced when printing. Even cheap printers have a resolution much higher than that of a screen. And clean scaling is, for obvious reasons, a boon to the partially sighted.
When we look at the hardware that was abundant at the time GDI was devised, the reasons for its limited capabilities are clear. Back then, video cards were dumb "framebuffers." They had a small amount of memory that represented the screen, and that was about the extent of their graphical capabilities. They couldn't draw vector graphics or store multiple bitmaps and textures or any of the things we take for granted today. The main processor would design what should be drawn, then copy that over to the buffer on the video card, which would display it directly on screen. With this scarcity of memory and processing power, the overall design made sense; it would have been too slow and used too much memory to do anything else.
So the GDI didn't offer many bells and whistles. There were commands for stretching and scaling bitmaps and drawing lines and text, but not really much more, and even those effects looked horrible because they operated on bitmaps; resizing and rotating and distorting bitmaps loses detail and tends to create jagged lines. Smooth animations were out of the question because there was no way of v-syncing.
Back then, it didn't really matter, because the hardware was so primitive you couldn't manage anything more. But technology has marched inexorably forward.
The beginnings of video acceleration
In the early 1990s, video cards started providing hardware assistance for the basic GDI operations like "draw line" and "copy bitmap"; they were marketed as "Windows Accelerators" and soon all video cards were "Accelerators." And that's been the state of the art of 2D video acceleration since. The cards can accelerate some basic drawing functions and can move blocks of pictures around, but that's it.
But acceleration didn't end there. During the late 1990s, the 3D accelerator entered the scene. Sure, 3D accelerators had the old 2D acceleration of old. But they could do so much more. Given a list of lines and triangles in a 3D space, they could draw the scene described. They could apply textures to those triangles and perform the transformations required to make the textures fit properly. And they could do it fast, so you could have thousands or millions of these triangles drawn each second, allowing for the kind of smooth and seamless animation we demand from our games. More recently the cards became even more powerful with the advent of shaders. This allowed them to perform complex calculations on each pixel in a scene so that you could, for example, apply gamma correction or motion blurring or blending between textures, all lightning fast and with minimal load on the main CPU. At the same time, video cards gained a load of memory for storing all these textures and scenes to be rendered.
The video card companies invested hundreds of millions of dollars developing this hardware. Yet in spite of these massive advances, the Windows desktop that we use every day doesn't take any advantage of it. It's still using dumb bitmaps.
The User API
The other part of the story is "User." User is the API responsible for windows, menus, and cursors. Applications call User functions to create a window, and User (in conjunction with the window manager, which in Windows doesn't exist as a clearly defined entity) then draws them. Communication between the application and the window manager is done using "window messages"; the window manager passes messages to the application such as "the mouse moved" or "a key was pressed", and the application then processes these messages. As far as User is concerned, "windows" aren't just the big things with the borders and the title bars; dialog boxes, scrollbars, list boxes, input boxes, and almost all the other interactive things you see on screen are also "windows." If it responds to the mouse or the keyboard, it's probably a window.
User also interacts with GDI; one of the messages that gets sent is a message to, say, "repaint your window." The application then makes the necessary calls to GDI to do that. The reason that this has to happen is because User and the window manager have no memory. The window manager knows which windows are onscreen, and it knows what the current screen looks like, but that's all. If one window is moved, uncovering part of another window, the window manager doesn't know what the newly uncovered window looks like. So it sends a message to the uncovered application to tell it "paint this part of yourself". If the application doesn't respond to the message (because it has locked up, for instance) then the window manager has nothing to draw, so it doesn't draw anything, instead leaving behind whatever happened to be there before it was uncovered. This is why one sees from time to time the "hall of mirrors" effect when applications crash on Windows.
There are other downsides to this approach; it makes it virtually impossible to have windows smoothly animated (because as one window moves, the windows below it will flicker as they redraw) or to have the fancy (if not especially useful) transparency effects we've seen on OS X. Windows 2000 did attempt to improve this situation somewhat by allowing windows to set themselves as being "remembered" (so that they could be redrawn without having to ask the application), but it's imperfect. Since it's not done across the board (because most applications don't work that way), it can only help when applications explicitly request it.
Again, in the context of the hardware available at the time, this made sense. It was much easier to just generate an image from scratch each time it needed to be displayed than to try to store every single window in memory and piece them together to provide the final image. To do that would have required far more memory than was available, and the cost of an occasional hall of mirrors was worth it. Better to have a system that was occasionally ugly but quick than one which looked a little better but was so slow as to be unusable.
As with GDI, this assumption no longer holds true. Computers and video cards now have gobs of memory; my video card has twice as much memory on it than the hard disk I used to run Windows 3.1, and a thousand times more than the video card I had back then. Nowadays it's not only practical to store information about the covered-up parts of windows (so that they can be revealed instantly)—it seems foolish not to. And if the window manager is going to remember all the windows' contents, then it would make sense to have it interact with applications differently; it shouldn't have to tell them when to paint the whole time. The programming model used by User also works poorly with the paradigms that have been in fashion for the past ten or fifteen years; it's just not very convenient to use. These days environments such as .NET and Java are abundant. An API which plays nicely with these environments would make development of high-quality user interfaces much simpler.
Now there are already ways of using these powerful new features on new cards; after all, there would be no point in having all this functionality if it wasn't usable. One of these is OpenGL. It was first released in 1992 by SGI, to unify the programming model used by various high-end 3D equipment. By the late 1990s, OpenGL acceleration was offered by regular low-end, consumer-grade hardware. Microsoft then developed their own 3D API which they named Direct3D. Early versions were regarded by developers as clumsy and inferior to OpenGL, but the present version (Direct3D 9) is generally regarded as being at least as good as OpenGL.
But our desktops don't use them. They're stuck with models that date back to the mid-1980s. That's what Vista is setting out to change.