WinFX: An All-Managed API
Subject:   PeekMessage,DispatchMessage
Date:   2003-12-09 15:00:04
From:   igriffiths
Response to: PeekMessage,DispatchMessage

First of all, there is backwards compatibility support. So all existing Win32 apps should carry on running just fine on Longhorn. Obviously they won't be written to use any of the new features of Avalon, so they won't take advantage of them, but they run just fine. Office runs perfectly well for instance. So does that old DOS application Visicalc, for that matter - Microsoft always maintain a very high level of backwards compatibility.

That said the old Win32 message pump doesn't appear to play a central role in the UI. But then you appear to be under the mistaken impression that it plays a more central role in Windows than it really does. Sockets are entirely unrelated to the message pump. (I wrote network adapter device drivers for several years a while back, so I'm fairly well acquainted with the innards of the Windows networking stack.) Networking is essentially based on Windows NT/2000/XP's native IO system, which has absolutely nothing to do with message pumps. The message pump is a user mode construct that you never have to interact with in either kernel mode or user mode networking code.

The only situations in which sockets and message loops appear to collide is if you use either the MFC socket classes or the VB socket library. Both of these end up using windows messages for the simple reason that both are designed to be able to raise events in a GUI application. But this is a feature of those class libraries, not a feature of sockets.

Many applications function perfectly without a message queue ever coming into existance. They are all server applications that never open a window, admittedly, but it illustrates that you don't need a message queue. (Windows doesn't actually create one until you ask for one, which again demonstrates that it's quite capable of functioning without one.) And the old Win32 message architecture is at the heart of a number of threading problems with GUI apps and also some COM applications, so getting rid of it would be no bad thing.

It's still supported, but only so that you can use legacy Windows and ActiveX components inside of Avalon applications, and so that the old COM threading models are still available if you need them. But other than support for legacy code, there's no fundamental reason for Win32 message loops.

(You do need some way for the OS to deliver notifications to the UI, but there's nothing sacred about the old message loop. Avalon appears to do things differently - rendering happens on a different thread from everything else for example.)