Holy cow, I wrote a book!
Long Zheng does it again. He follows up his interview with Hamad Darwish with a report on what Hamad has been doing lately, as well as links to high resolution versions of the entire Vista wallpaper photo shoot, including photos that didn't make the final cut.
This computer didn't die like the previous one; it merely outlived it usefulness.
In its prime, the machine was a force to be reckoned with. It was about the size of a small refrigerator and generated about as much noise as a vacuum cleaner. It contained four, count 'em, four Alpha AXP processors, each running at a mind-boggling 400 MHz. It had one gigabyte of RAM and thirteen gigabytes of hard drive space (striped over over a dozen fast SCSI drives). Hey, back in the 1990's these were impressive hardware specs.
When it was in active use, the machine ran a batch file that simply grabbed the latest source code to the shell, compiled it (if there were any changes made since the last iteration), and then repeated. It was called the "hourly build machine" since it took about an hour to compile the shell from scratch. And if there were any errors in the build, it sent mail to the shell team saying, "The Alpha AXP build is broken. Go fix it." It ran other tests on the side to verify that, for example, resources didn't change that would either generate compatibility problems or cause the localization team to get upset. Since very few people on the shell team had Alpha AXPs, the "hourly build machine" was the best chance of catching Alpha-specific build issues before the official build lab noticed the following morning.
When support for the Alpha AXP was officially dropped, the responsibility for producing hourly builds had long since fallen to two other machines, but the Alpha AXP continued to grab the latest source code and index it, making the index available to the entire Windows team. (And since it didn't have to do any compiling, it grabbed the source code to the entire operating system, not just the shell.) Having a search engine running against the entire source code to the operating system you're working on is very handy.
Ultimately, though, the machine was retired. What was once impressive hardware specifications became barely yawn-worthy. The machine sat in my office and served as a table for several years. (I can't even say "an expensive table" since the value of the computer was probably nil by this point.) It travelled with me through several office moves, until I eventually decided to put the machine out to pasture. I wiped the hard drives of all sensitive information and cajoled one of my colleagues who owned a pick-up truck into helping me load it up and taking the machine to the archives department where it now spends its time swapping stories of old times with IBM PC XTs and other hardware from times past.
(The archives department serves an important function beyond merely being a repository of Microsoft history. It occasionally becomes necessary to actually run an operating system from times past for various reasons, be they educational, nostalgic, or legal.)
A good friend of mine forwarded me this help-wanted ad on CraigsList:
Need a programmer to make a Search Engine like Google I'm looking for some Programmer(s) who can help me create a search engine like Google. Only qualified person(s) encouraged to apply. Compensation: no pay
Need a programmer to make a Search Engine like Google
I'm looking for some Programmer(s) who can help me create a search engine like Google. Only qualified person(s) encouraged to apply.
Compensation: no pay
Good luck with that.
I promised to talk more about NMI, so here it is.
What generates an NMI? What does it mean?
The first question is easy to answer but doesn't actually shed much light: Any device can pull the NMI line, and that will generate a non-maskable interrupt. Back in the Windows 95 days, a few really cool people had taken the ball-point pen trick one step further: They had a special expansion card in their computer with a cord coming out the back. At the end of the cord was a momentary switch like the one you might see on a quiz show. If you pressed it, the card generated an NMI. No fumbling around with ball-point pens for these folks, no-ho! (To be honest, I had two of these. One of them was a simple NMI card, triggered by a foot pedal! The other was really a card with a high-resolution real-time clock that could be used for performance analysis. I used the NMI button far more often than the timer...)
In practice, the only device that generates an NMI (on purpose) is the memory controller, which raises it when a parity error is detected. The non-geek explanation of a parity error: Your memory chips are acting flakey.
Here's what a parity error looks like. It shows up as a mysterious "Hardware Malfunction" error.
Now, it's possible that a device may be generating an NMI by mistake. For example, in Wendy's case, it may have been due to damaged caused by overheating.
If you suspect your memory chips, you can run a memory diagnostic tool to see if it can find the bad memory.
My colleague Keith Moore reminded me that paradoxically, on the IBM PC-AT, you could mask the non-maskable interrupt! This definitely falls into the category of "Unclear on the concept." The masking was done in hardware that could be configured via some magic port I/O. It prevented the NMI from reaching the CPU in the first place. (NMI is still not maskable in the CPU.)
I learned this from Yes, Minister. They call it the politician's fallacy:
As befits its name, you see it most often in politics, where poorly-thought-out solutions are proposed for urgent problems. But be on the lookout for it in other places, too. You might see somebody falling victim to the politician's fallacy at a business meeting, say.
Something else I picked up is what I'm going to call the politician's apology. This is where you apologize for a misdeed not by apologizing for what you did, but rather apologizing that other people were offended. One blogger coined the word "fauxpology" to describe this sort of non-apology. In other words, you're not apologizing at all! It's like the childhood non-apology.
"Apologize to your sister for calling her ugly."
"I'm sorry you're ugly."
In the politician's apology, you apologize not for the offense itself, but for the fact that what you did offended someone. "I'm sorry you're a hypersensitive crybaby."
The president regretted any hurt feelings his statements may have caused.
Another form of non-apology is to state that bad things happened without taking responsibility for causing them:
There should not have been any physical contact in this incident. I am sorry that this misunderstanding happened at all, and I regret its escalation and I apologize.
This particular non-apology even begins with the accusation that the other party was at fault for starting the incident!
What bothers me is that these types of non-apologies are so common that nobody is even offended by their inadequacy. They are accepted as just "the way people apologize in public". (It's become so standard that Slate's William Saletan has broken it down into steps for us.)
A commenter asked, "As an application programmer, can I really ignore DDE if I need to interact with explorer/shell?"
The answer is, "Yes, please!"
While it was a reasonable solution back in the cooperatively-multitasked world of 16-bit Windows where it was invented, the transition to 32-bit Windows was not a nice one for DDE. Specifically, the reliance on broadcasts to establish the initial DDE conversation means that unresponsive programs can jam up the entire DDE initiation process. The last shell interface to employ DDE was the communication with Program Manager to create program groups and items inside those groups. This was replaced with Explorer and the Start menu back in Windows 95. DDE has been dead as a shell interface for over ten years.
Of course, for backwards compatibility, the shell still supports DDE for older programs that choose to use it. You can still create icons on the Start menu via DDE and you can still register your documents to launch via DDE if you really want to, but if you take a pass on DDE you won't be missing anything.
On the other hand, even though there is no technological reason for you to use DDE, you still have to be mindful of whether your actions will interfere with other people who choose to: If you stop processing messages, you will clog up DDE initiation, among other things. It's like driving an automatic transmission instead of a manual transmission. There is no requirement (in the United States, at least) that you own a manual transmission or even know how to operate one. But you still have to know to ensure that your actions do not interfere with people who do have manual transmissions, such as watching out for cars waiting for the traffic light to change while pointed uphill.
You know, it's gotten to the point where I wouldn't be surprised if O. J. Simpson wrote a new book titled If I Were the Father of Anna Nicole Smith's Baby.
Just saying.
Every year, I put together a little pocket guide to the Seattle Symphony subscription season for my symphony friends to help them decide which ticket package they want. As before, you might find it helpful, you might not, but here it is anyway.
Notes:
This chart doesn't include "one-off" concert series such as the Visiting Orchestras or Distinguished Artists series.
Explanations for the partial blocks: The 18A series gets the 11/8 program; 18B gets 11/10. The Musically Speaking concerts typically omit one of the pieces from the evening program, substituting on-stage commentary.
The comments column very crudely categorizes the works to assist my less-classically-aware friends. This is, of course, a highly subjective rating system, but I tried to view each piece from the ears of somebody new. Thus, I rated downward pieces that I personally like but which others might not and rated up pieces that I may not find musically satisfying but which nevertheless tend to be crowd-pleasers. These predictions have, of course, proven wrong in the past. For example, this season, my rating of "Okay" for Copland's Music for the Theatre was too optimistic.
Here's what the comments mean. Note that they do not indicate whether the piece is significant in a musicological sense; they're just my guess as to whether my friends are going to like it.
A question mark means that I am not familiar with the piece and am basing my evaluation on what I know about the composer (or am just guessing).
Now that you understand the intended purpose of LockWindowUpdate, I'm going to tell you why you don't want to use it, not even for its intended purpose!
LockWindowUpdate
You have to go back to the historical context in which LockWindowUpdate was created. Rewind back to 16-bit Windows, specifically Windows 3.1. Back in these days, memory was expensive. Video drivers were pretty limited in functionality. There was no DirectX. There was no AlphaBlend function. All you had was a screen buffer. The LockWindowUpdate function let you take control over one window's portion of that screen buffer so you could apply your fancy effects to the window without that window's knowledge.
It's been over a decade since Windows 3.1, and in the meanwhile, we gained DirectX overlays, regional windows, layered windows, alpha blending, desktop composition, all sorts of cool graphical effects that weren't available back in the old days. In particular, those layered windows and regional windows pretty much let you do nearly all of the stuff you would have wanted to do with LockWindowUpdate anyway. If you want to draw a highlight around a window, you can position a regional window around it. If you want to draw a drag image over a window, you can just create layered window and position it over the target window. Give the layered window a region and whatever fancy alpha channel you want, and let the graphics engine do the heavy lifting of alpha blending and composition. Even better, the layered window can extend outside the window you are dragging over, something that LockWindowUpdate can't do. (You can see this effect in Windows XP if you do a "select all" in an Explorer window and drag the entire selection around the screen. Notice that the drag image is not constrained to the boundaries of the window you are dragging over.)
What's more, in the exciting new composited world of Vista's desktop window manager, LockWindowUpdate is even less desirable. Locking a particular window for update isn't so bad since the desktop window manager can just give you the backing bitmap for the window. But if you lock the entire screen (which I've seen may people do), the desktop window manager needs to compose all of the windows into an actual bitmap that it can give you when you call GetDCEx with the DCX_LOCKWINDOWUPDATE flag. The desktop window manager does composition on the fly with the help of DirectX and accelerated video drivers. The result of all this composition normally goes straight to the screen without actually residing in a "composited" bitmap anyway. But if you lock the screen and ask for a DC to it, the desktop window manager needs to emulate the old behavior and give you access to something that represents what you would have gotten if there were no composition in the first place. That ain't cheap.
GetDCEx
DCX_LOCKWINDOWUPDATE
Epilogue. I'm not sure if this series was a success or not. My goal was just to help people use LockWindowUpdate more effectively and guide them towards alternatives when LockWindowUpdate is the wrong tool for the job. In other words, it's an article about LockWindowUpdate, not function documentation. I tried to keep the presentation light, but I guess my jokes fell flat, and people just used them as a springboard for negative comments.
And extra thanks to the people who took it as an opportunity to complain about the documentation. I mean, duh, if the documentation were perfect, I wouldn't have written this series in the first place. Though these people also neglected to read all of the documentation; they looked only at the function description page. There's more to documentation than dry function descriptions, people! The function description is a reference; you go there when you already know what's going on and you just need to fine-tune a detail. The real learning happens in the overviews and articles. If you want to learn how to operate your radio, you don't read the schematic first.
I think Ronald D. Moore is really onto something when he says, "You have to be tough enough to listen to the podcast."
One of my colleagues recently posted the story of the work he did to get laptops to resume quickly. The fun part was implementing the optimizations in the kernel. The not-fun part was finding all the drivers who did bad things and harassing their owners into fixing the bugs.
One some laptops, he could get the resume time down to an impressive one second. And then entropy set in.
It's likely you've never seen a real off-the-shelf laptop resume this quickly. And the reason is that as soon as you stop twisting the arms of all the driver writers, they stop worrying about how fast your laptop resumes and go back to worrying about when they can get their widget driver mostly working so they can get through WHQL and sell their widget.
But now you have some tools to fight back, at least a little bit. The second half of that article explains how to use the event viewer to track down which drivers are ruining your resume time and disable them.