Why Avalon Is Getting So Much Hype
So everyone's been speculating about Avalon. It sounds like it's going to be really cool.
Out of all the tidbits I've heard through various public sources, I think the following interest me the most:
1) No Message Pumps!
One of the big issues with Windows GUI programming is developers sometimes get lazy(or don't have time to write properly-threaded code), so you end up with a program that does a large amount of work in the GUI thread. If that is not done without pumping the message queue intermittently, the program will appear to stop responding completely - as if it's frozen. On XP, a kludge for this was created - ghost windows. Ghost windows will replace visible windows in a thread that is not responding, if the thread's message queue stops pumping input messages. A ghost window is created by the window manager, under the context of the shell process, with the class name 'Ghost'. The contents of the windows that are not responded are blitted to these replacement ghost windows. Ghost windows allow all generic window manager interaction - if a window could be resized, it's replacement ghost is resizable. If it can be minimized, it's replacement ghost can be minimized. The only really visible difference in a ghost window apart from the lack of user-app interaction is the lack of a menu bar. Also, if you try to close a ghost window, the text will change to the original text + (Not Responding), and you will get the end process dialog. On 2k, the kludge originally was something like the following(not entirely clear on this, didn't take the time to check it out): WM_NULL is posted to the window along with the other messages when the close button is clicked. If it is not responded to within a certain amount of time, the end process dialog will appear.
Message Pumps were cool at one time, but now they're pointless. We have all sorts of crazy messages that would be fine as properties - WM_GETMINMAXINFO and the like. Getting rid of the message pump is going to be big for both end users and programmers - I am guessing when and where you do your 'work' won't be such a big deal, and the end user doesn't end up feeling like their computer is acting "flaky" and itching for a reboot.
2) Killer windows, man!
As we saw from WinHEC, we'll be able to do some crazy 3d freeform stuff. This and the rest of the compositor features(which I'll theorize over in my next post) have me salivating. Yes folks, I've had dreams about the compositor. Freaky? Yea. But when you consider my job it's not that bad - what we're doing with WindowFX will be much easier in Longhorn. One of the big things we'll be doing is designing a new version of WindowFX to take full advantage of the compositor.
3) Nicer Interfaces
Avalon's rendering power is supposed to be a combination of DirectX, GDI+, and DHTML technologies. This will allow some pretty awesome interfaces, as can be seen from the supposed Aero shots. The only thing that worries me here is the possibility of a lack of structure. If anyone can design interfaces any way they want to, it's possible we'll have an outbreak of alien-like interfaces that "look really cool" but are impossible to use. Sort of like the custom control frenzy in the 90's, but this time with the entire application look and feel. Without guidelines or a general paradigm to conform to, this is looking like a possibility.
4) Bye-Bye USER/GDI?
I've been thinking about this one a lot. Will avalon be built on top of USER for compatibility? Most of the guts of the window manager sit in win32k.sys, and that's a really complex design, which makes me think that rather than building a compatibility layer for classic apps, avalon will build on top of, or beside them. Otherwise, this will involve a lot of changes to win32k. Sure, 2 years is a long time and that's a possibility, but if they've got something to show us now, I'm guessing it's built on top of existing architecture.