The Old New Thing
Practical development throughout the evolution of Windows.
Latest posts
Enumerating notification icons via UI Automation
Walking the tree.
Some parts of an interface can change but others can't
When I wrote about asking the compiler to answer calling convention questions, some people were concerned about whether this was a reliable mechanism or whether it was relying on something that can change in the future. This is a special case of the question, "What parts of an interface can change, and what can't?" And it all boils down to compile-time versus run-time. Assuming you are interested in binary compatibility (as opposed to merely source compatibility), then a decision made at compile-time can never be changed because the decision is already hard-coded into the application. For example, if you ha...
Why is there a 64KB no-man's land near the end of the user-mode address space?
We learned some time ago that there is a 64KB no-man's land near the 2GB boundary to accommodate a quirk of the Alpha AXP processor architecture. But that's not the only reason why it's there. The no-man's land near the 2GB boundary is useful even on x86 processors because it simplifies parameter validation at the boundary between user mode and kernel mode by taking out a special case. If the 64KB zone did not exist, then somebody could pass a buffer that straddles the 2GB boundary, and the kernel mode validation layer would have to detect that unusual condition and reject the buffer. By having a guaranteed in...
Standard handles are really meant for single-threaded programs
When I discussed the conventions for managing standard handles, Sven2 noted that I implied that you need to call with a new handle if you close the current handle and asked "Wouldn't it make more sense to call it the other way round? I.e., first set the new handle, then close the old one? It would ensure that any other thread that runs in parallel won't get an invalid handle." Yes, that would make more sense, but only by a little bit. If you have one thread changing a standard handle at the same time another thread tries to use it, you still have the race condition, as Cesar noted, where the thread that gets ...
Microspeak: All-up
In other words: All-inclusive.
Enumerating cyclical decompositions with Stirling numbers
This whole enumeration nightmare-miniseries started off with Stirling numbers of the second kind. But what about Stirling numbers of the first kind? Those things ain't gonna enumerate themselves! The traditional formulation of the recursion for Stirling numbers of the first kind (unsigned version, since it's hard to enumerate negative numbers) goes like this: c(n + 1, k) = n · c(n, k) + c(n, k − 1). although it is more convenient from a programming standpoint to rewrite it as c(n, k) = (n − 1) · c(n − 1, k) + c(n − 1, k − 1). The Wikipedia article explains ...
Why is 0x00400000 the default base address for an executable?
Rewind to 1987.
In the red corner, EXCEPTION_INT_DIVIDE_BY_ZERO and STATUS_INTEGER_DIVIDE_BY_ZERO; and in the blue corner, EXCEPTION_INT_OVERFLOW and STATUS_INTEGER_OVERFLOW
The exception code (and its doppelgänger ) is raised, naturally enough, when the denominator of an integer division is zero. The x86 and x64 processors also raise this exception when you divide by , or more generally, when the result of a division does not fit in the destination. The division instructions for those processors take a 2N-bit dividend and an N-bit divisor, and they produce N-bit quotient and remainder. Values of N can be 8, 16, and 32; the 64-bit processors also support 64. And the division can be signed or unsigned. Therefore, you can get this exception if you try to divide, say, 2³&s...
You can name your car, and you can name your kernel objects, but there is a qualitative difference between the two
A customer reported that the appeared to be unreliable. We have two threads, one that waits on an event and the other that signals the event. But we found that sometimes, signaling the event does not wake up the waiting thread. We have to signal it twice. What are the conditions under which will ignore a signal? // cleanup and error checking elided for expository purposes void Thread1() { // Create an auto-reset event, initially unsignaled HANDLE eventHandle = CreateEvent(NULL, FALSE, FALSE, TEXT("MyEvent")); // Kick off the background thread and give it the handle CreateThread(..., Thread2, event...