The Old New Thing
Practical development throughout the evolution of Windows.
Latest posts
The cursor isn't associated with a window or a window class; it's associated with a thread group
In my earlier discussion of the fact that changing a class property affects all windows of that class, commenters LittleHelper and Norman Diamond wanted to know "Why is the cursor associated with class and not a window?" This is another one of those questions that start off with an invalid assumption. The cursor is not associated with a class. The cursor is not associated with a window. The cursor is associated with an input state. (Initially, each thread has its own input state, but functions like can cause threads to share their input states.) As we saw when we explored the process by which the cursor ge...
The 2010 Niney Award nominees have been announced
The nominees for the first (annual?) Niney Awards have been announced. The Nineys are an award which recognizes those who have had the greatest impact on the technical/developer community over the past year. Winners are selected by you, the technical/developer community. The winners will be announced at the MIX11 conference in April. But before they can announce winners, they need to collect votes. That's where you come in. Cast your vote online in the following categories: Now, it so happens that among the nominees is an author of a somewhat unsucessful book on programming (not to be confused with an au...
Ready… cancel… wait for it! (part 3)
A customer reported that their application was crashing in RPC, and they submitted a sample program which illustrated the same crash as their program. Their sample program was actually based on the AsyncRPC sample client program, which was nice, because it provided a mutually-known starting point. They made quite a few changes to the program, but this is the important one: (It was actually more complicated than this, but this is the short version.) The program was crashing for the same reason that Wednesday's I/O cancellation program was crashing: The program issued an asynchronous cancel and didn't wait f...
I am no longer impressed by your fancy new 10,000 BTU hot pot burner
Two years ago, we had a gathering at my house for some friends for hot pot, the traditional way of ringing in the lunar new year (which takes place today). It was actually a bit of a cross-cultural event, since the attendees came from different regions of Asia, where different traditions reign. (And the American guests just had to choose sides!) My house has but one portable stove for hot pot, so one of the guests brought her own unit, a unit as it turns out which was purchased specifically for the occasion, which gleamed in the light and proudly proclaimed 10,000 BTU of raw heating power. This was cause for mu...
Ready… cancel… wait for it! (part 2)
A customer had a question about I/O cancellation. They have a pending call with a completion procedure. They then cancel the I/O with and wait for the completion by passing as the parameter to . Assuming both return success, can I assume that my completion procedure will not be called after GetOverlappedResult returns? It appears that GetOverlappedResult waits non-alertably for the I/O to complete, so I'm assuming it just eats the APC if there was one. But if an APC had been posted just before I called CancelIoEx, will it also cancel that APC? does not magically revoke completion callbacks. Why should it?...
Ready… cancel… wait for it! (part 1)
One of the cardinal rules of the structure is the structure must remain valid until the I/O completes. The reason is that the structure is manipulated by address rather than by value. The word complete here has a specific technical meaning. It doesn't mean "must remain valid until you are no longer interested in the result of the I/O." It means that the structure must remain valid until the I/O subsystem has signaled that the I/O operation is finally over, that there is nothing left to do, it has passed on: You have an ex-I/O operation. Note that an I/O operation can complete successfully, or it can comp...
There is no longer any pleasure in reading the annual Microsoft injury reports
Microsoft is required by law to file reports on employees who have sustained injuries on the job. They are also required to post the reports in a location where employees can see them. These reports come out every year on February 1. Back in the old days, these reports were filled out by hand, and reading them was oddly amusing for the details. My favorite from the mid 1990's was a report on an employee who was injured on the job, and the description was simply pencil lead embedded in hand. Sadly, the reports are now computerized, and there isn't a place to describe the nature of each injury. It's just a b...
Solutions that require a time machine: Making applications which require compatibility behaviors crash so the developers will fix their bug before they ship
A while ago, I mentioned that there are many applications that rely on messages being delivered even if there is nothing to paint because they put business logic inside their handler. As a result, Windows sends them dummy messages. Jerry Pisk opines, Thanks to the Windows team going out of their way not to break poorly written applications developers once again have no incentive to clean up their act and actually write working applications. If an application requires a dummy WM_PAINT not to crash it should be made to crash as soon as possible so the developers go in and fix it before releasing their "code"...
Some remarks on VirtualAlloc and MEM_LARGE_PAGES
Large pages are a special feature for dedicated server processes.