Women in Technology

Hear us Roar

  WinFX: An All-Managed API
Subject:   PeekMessage,DispatchMessage
Date:   2003-12-09 09:18:22
From:   anonymous2

You haven't answered the primary question anyone asks about a platform that would not use WIN32. That's the question of windows and message pumps. When you know how much anything works with it, including sockets ( :-) ), where are the message pumps gone.

The marketing brochure says Avalon works without message pumps.

This cannot be true (it's marketing after all), otherwise this would also completely and utterly obsolete anything Windows-like. In other terms, no pre-Longhorn app would be able to run on a Longhorn OS.

So the message pump is still there, it's just hidden (like the UI thread in winforms).

That being said, control over the message pump is critical for many apps, so if the new framework doesn't provide any direct/indirect level of control over it, I am afraid that it will be very hard to come up with high performing and well-behaving apps that would at the same time be nice citizens to the overall CPU and system loads.

My 0.5 cent.
Stephane Rodriguez.

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • Ian Griffiths photo PeekMessage,DispatchMessage
    2003-12-09 15:00:04  Ian Griffiths | O'Reilly Author [View]

    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.)