Showing results for Code - The Old New Thing

Today, we'll illustrate the consequences of the way the window manager synchronizes input when two or more threads decide to share an input queue. Since I need to keep separate state for the two windows, I'm going to start with the new scratch program and make the following changes: #include <strsafe.h> class RootWindow : public Window...

Now that we've had a quick introduction to asynchronous input, let's look at some of the details. Remember, this is a peek under the hood at how the sausage is made. The algorithm described here is not part of the API contract and it can change at any time, as long as it services the overall goal of serializing input. Let's start by looking at ...

One of the topics I covered at my PDC talk was the asynchronous input model. I don't think I ever discussed it on this Web site, so I guess I'll do it now, so that I can point people at it in the future. In the old days of 16-bit Windows, input was synchronous. All input went into a system-wide input queue, and the intuitive rule for input proce...

Ultimately, you can't stop somebody from ignoring the words Confidential at the top of a document and whipping out a digital camera and taking a picture of the screen. But at least starting in Windows 7 you can make it a little more difficult. Take our scratch program and add this one line: ... SetWindowDisplayAffinity(hwnd, WDA...

Regardless of which interpretation you use, it remains the case that posted messages are processed ahead of input messages. Under the MSDN interpretation, posted messages and input messages all go into the message queue, but posted messages are pulled from the queue before input messages. Under the Raymond interpretation, posted messages and in...

There are multiple ways of viewing the interaction between posted messages and input messages. MSDN prefers to view posted messages and input messages as part of one giant pool of messages in a message queue, with rules about which ones get processed first. I, on the other hand, prefer to think of posted messages and input messages as residing in ...

The function zeroes out memory in a way that the compiler will not optimize out. But what's the point of doing that? Does it really make the application more secure? I mean, sure the data could go into the swap file or hibernation file, but you need to have Administrator access to access those files anyway, and you can't protect yourself against a...

You already know how to create a shortcut: #include <windows.h> #include <tchar.h> #include <shlobj.h> #include <atlbase.h> // class CCoInitialize incorporated here by reference int __cdecl _tmain(int argc, TCHAR **argv) { // error checking elided for expository purposes CCoInitialize init; CComPtr<IShellLink> ...

As we well know, the window manager generates various messages on-demand rather than posting them into the queue at the time the event occurs. But what happens if you manually post one of these messages, like ? Does that clear the internal flag that says "This window needs a paint message?" Nope. The window manager does not have a prank call...

We all know that the generated-on-demand messages like , , and messages are not posted into the queue when the corresponding event occurs, but rather are generated by or when they detect that they are about to conclude that there is no message to return and the generated-on-demand message can be returned. When this happens, the window manager c...