The Old New Thing
Practical development throughout the evolution of Windows.
Latest posts
No, you can't ask whether your notification icon is visible or not
A customer asked what started out as a simple question, but by now you know that this sort of simple question only raises new questions: Is there a way that we can detect that the user has hidden our notification icon? No, there is no way to ask whether your notification icon is hidden or visible. Users decide which icons they want to see, and you don't get to snoop in on the users' decisions. Questions like this scare me, because it sounds like this customer's program is going to respond to the user's choice to hide their icon by doing something even more annoying. This is another demonstration of Le Chatel...
There's only so much you can do to stop running code from simulating UI actions
Commenter KiwiBlue asks whether Captcha-style tests were considered to prevent unsigned drivers from programmatically clicking the 'Install anyway' button. I'm sure somebody considered it, but Captcha has its own problems. "Type the (distorted) letters below"-type Captcha cannot be used by people with visual impairments, people who are dyslexic, or people who simply are not familiar with the Latin alphabet. (Believe it or not, the vast majority of people on the planet have a native language which does not use the Latin alphabet.) Using an audio captcha runs into the problem of different accents, letters whose ...
Even if you have a lock, you can borrow some lock-free techniques
Even if you prefer to use a lock (after all, they are much easier to program), you can borrow some lock-free techniques. For example, consider this: There are some concerns here. First of all, there's the lock hierarchy issue: If reticulating a spline takes the geometry lock, that may violate our lock hierarchy. If the lock is a hot lock, you may be concerned that all this gorilla stuff will hold the lock for too long. Maybe rendering a gorilla is a slow and complicated operation because it's hard to get the fur just right. These issues become less onerous if you switch to a lock-free algorithm, but that...
The performance improvements of a lock-free algorithm is often not in the locking
GWO wonders what the conditions are under which the lock-free version significantly outpeforms a simple critical section. Remember that switching to a lock-free algorithm should be guided by performance measurements. Switching from a simple algorithm to a complex one shouldn't be done unless you know that the simple algorithm is having trouble. That said, here are some non-obvious advantages of a lock-free algorithm over one that uses a simple lock. (Later, we'll see how you can take advantage of these techniques without actually going lock-free.) Consider a program that uses a simple critical section to ...
Corrections to Patterns for using the InitOnce functions
Adam Rosenfield pointed out that it is not possible to fail an asynchronous initialization; if you pass when completing an asynchronous initialization, the function fails with . (Serves me right for writing an article the night before it goes up.) A more correct version is therefore In other words, the pattern is as follows: While I'm here, I may as well answer the exercises. Exercise: Instead of calling with , what happens if the function simply returns without ever completing the init-once? Answer: The structure is left in an asynchronous initialization pending state. This is fine, because the n...
Endorsement: Aaron Margosis's Unintended Consequences of Security Lockdowns talk at TechEd
At TechEd 2011 North America in Atlanta, Aaron Margosis is presenting a talk on Unintended Consequences of Security Lockdowns. I've seen the internal version of his talk and I give it two thumbs up. If you're going to be at TechEd North America, consider adding it to your schedule.
Visual Studio 2005 gives you acquire and release semantics for free on volatile memory access
If you are using Visual Studio 2005 or later, then you don't need the weird function because Visual Studio 2005 and later automatically impose acquire semantics on reads from volatile locations. It also imposes release semantics on writes to volatile locations. In other words, you can replace the old function with the following: This is a good thing because it expresses your intentions more clearly to the compiler. The old method that overloaded forced the compiler to perform the actual compare-and-exchange even though we really didn't care about the operation; we just wanted the side effect of the Acqui...
Back from Las Vegas, and now my clothes smell like cigarette smoke
I actually came back Thursday night, but I've been too lazy to jot down some reactions until now. There are signs on the street directing you to a tram connecting the Monte Carlo hotel with the Bellagio. but once you follow the first sign (that takes you into the casino), there are no more signs telling you how to get to the tram. The tram is a lie. Actually, the tram does exist, but it's not marked. You have to walk through the entire Monte Carlo casino to the Street of Dreams shops, and then past them and up a flight of stairs to the tram station. When you reach the Bellagio, you then have to do the reverse...
Don't forget to include the message queue in your lock hierarchy
In addition to the loader lock, the message queue is another resource that people often forget to incorporate into their lock hierarchy. If your code runs on a UI thread, then it implicitly owns the message queue whenever it is running, because messages cannot be dispatched to a thread until it calls a message-retrieval function such as or . In other words, whenever a thread is not checking for a message, it cannot receive a message. For example, consider the following code: If belongs to another thread, then you have a potential deadlock, because that thread might be waiting for your critical section. ...