Steve, a former C++ guy and current PCP guy, tells stories very well... just three of the reasons I like him. He blogs very infrequently, but when he has an update it's worth reading. This one is funny and informative. Plus, it features links to videos of presentations about the Parallel Computing Initiative. I've linked in the past to videos in English that are hosted on a page in French, so I know you can all handle it. Consider it Canadian Content even though the videos are from Paris. Go, read, watch, you'll enjoy it.

Billy is one of my heroes. He knows how to solve problem with software and he knows how to speak his mind. Here he is talking about WPF and Silverlight - shiny new ways of making applications, that work best in the hands of someone who's been making applications a long time and knows a thing or two about users and user interfaces. If you missed him on DNR TV, here's that episode. This one lets you see what he's talking about - highly recommended.

I love reading Internet histories. Some say it's because I was around for most of it but not so! The Internet was 20 years old when I started using it almost 20 years ago. Here's a nice summary that starts with the idea of packet switching and goes through iTunes, PayPal, MySpace and YouTube. It's a good read.

FreeRice is a strange little game that asks you what words mean. Does rejuvenate mean bewilder, pierce, evade, or restore? As you play, it assigns you a score, the higher the better, and also tracks the number of grains of rice that will be donated to the United Nations' World Food Program.

If you get a question right, you are asked harder and harder questions. The first time I tried this, I got the first 25 words in a row correct and then missed flagitious. I noodled around for a while and my score was around 49. They say over 48 is rare. Months later, with some time to kill online, I tried it again and my score topped out around 53. Wow.

They say "FreeRice has generated enough rice to feed more than two million people since it started in October 2007" although I guess that means two million people one meal each, it's still pretty impressive. And they've added subjects like Math and Chemical Symbols, though I haven't tried those. Give it a whirl, it's fun!

One of the most mind-clearing features of C++, C#, VB, and their ilk are exceptions. Rather than constantly checking a cascading series of return values, looking for false, -1, null, and whatever other error-signalling values you made up on the day you were writing the code, you can write relatively clean and neat code knowing that catastrophic errors (we have no more memory, the file you just chose from a list no longer exists, apparently I'm not allowed to write to the hard drive at all) will be handled. In C++, the "unwinding the stack" aspect of exceptions, with the memory cleanup and destructor-calling done for you, is a big part of writing clean code that is also memory-leak-free.

But have you ever thought about what happens to half-constructed things when an exception goes off? That is, when the constructor throws an exception before its work is done? I have had people tell me "oh simple, never throw an exception in a constructor." Wrong! A major motivation for the existence of exceptions is the existence of methods (like constructors) that don't have a return value to check. The rule you're half-remembering is "never throw an exception in a destructor" and the reason for that is to prevent weirdness when an exception triggers an unwinding and some destructors and then one of them throws another exception.

So what does happen to a half constructed object when an exception is thrown in the constructor? Who better to ask than Herb Sutter? He shows how C++, C#, and Java all answer this question... and his commenters toss in some other languages too.

Others have noticed this (Alexey Govorin, for example) but I tend to forget about it until just before I'm going into a meeting and feel that an export of work items would be helpful. I have some queries set up in VSTS that include the bug description. Here's how they look in Visual Studio.

Description is quite a long field, and when I open the query in Excel (didn't know you could do that? Right click the query in the Team Explorer pane) I see this:

Some, but not all, of the Descriptions are coming up all ####. Now this is what Excel does when something is too long for the column width. So it makes sense to look at things like widening the column, turning on Wrap Text, and the like. But the quickest thing that works for me is this: select the column. On the ribbon, drop down the formatting choice and choose Number. Not Text, which is what I would expect, but Number. Presto - I see all my Description entries.

Why does this work? I have no idea. But I hope this helps someone else.

Microsoft Canada is trying something different this fall and winter. A paid conference featuring material from this year's TechEd USA, delivered by excellent local speakers and coming to a city near you. Some cities have two day events, others a single day.

Toronto, October 29th and 30th

Montreal, November 6th and 7th

Ottawa, November 27th

Winnipeg, December 4th

Calgary, December 10th and 11th

Halifax, December 17th

Vancouver, January 21st and 22nd

What will the talks be like? What will it cost? Will there be cool swag? The web site doesn't really say right now, but I've been told the talks will be actual TechEd talks, the speakers will be industry leaders (my friends and colleagues, maybe me if we can make the dates work), and there will be 5 or so tracks, meaning over 30 sessions, so something for everybody. The early bird discounts will be substantial, so watch that web site for updates!

Some time ago a prospect called me to ask if I could help him solve a really frustrating problem. He had some software that was working and that he had delivered to dozens of clients, but sometimes it froze. It featured a lot of timers and he thought the problem was that one of them stopped firing, but he wasn't really sure. Could I do a code review for him and find where he had been stupid or sloppy to cause this problem?

So this is an intriguing concurrency problem, because multiple overlapping timers are not something you can definitively test, so I answered him "sure, send me the code." He sent it along and unfortunately it was really quite well written. That's unfortunate because I couldn't point to some obviously sloppy or stupid code and say "fix this and all will be well." We gave him some advice about how to gather problem information from users when they reported that one of the clock/timers "froze", and wished him luck.

Months later he came back, saying that it was a distinguishable subset of his clients that were having the problem, and please could we look again? He sent us the source code, as well as a deploy package that had gone to the most recent client to experience the problem. At first, we couldn't build his source code, because he had a whole pile of custom controls and funny license files and so on. So while we were waiting for him to send us things, we played with the executable. We couldn't make it misbehave. If repro cases don't come easily I usually switch to reading the code and imagining what could cause what I'm seeing, but when that doesn't work I'm back to trying for a repro. We were hoping it was having some sort of leak - memory, handles, something like that - which was freezing or hanging it. Repeated perusals of the source code convinced us the timers were a red herring, leaving mystery leaks as our best guess.

Did you know you can get Task Manager to show you more than just memory and CPU usage for your applications? On the View menu, choose Select Columns:

Then check off what you want, such as Handles and GDI Objects. Now watch while the application runs:

In this case, the deployed application didn't have a memory or handle leak, but it did seem to have a GDI Objects leak. The count kept going up, and never went down. We even discovered a way to make it go up -- there were buttons in the UI forming a toolbar of sorts, and they had a special effect as you moused over them and moused off again. Every time we caused the special effect to fire, the GDI Objects count would go up. This is the sort of thing that's impossible for developers to repro, because we don't idly wave our mouse back and forth along a toolbar wondering which button we should click. We test for like 5 minutes and say "looks ok to me." But we had been told that the freezes generally only happened when the application ran longer than usual - 4 hours rather than the usual 2 or 3. So we were hoping for some sort of leak that generally had no consequence, but could kill you if you waited long enough. So having learned how to drive the count up, we sat there waving the mouse around and driving it up. When we drove it past 10,000 - the application froze. Yay! Repro!

So we went into the source to reproduce it under the debugger - but the version we built from the source he sent didn't show the same behaviour - the GDI Objects count was well behaved and went up and down a little bit, never getting anywhere near 1,000 never mind 10,000. And interestingly, the source code he had sent us just used regular buttons in that toolbar like area. Aha! I blame the special button.

I asked him, since I didn't have the source for the version that was freezing, to tell me more about the button and where it came from. He told me the name and the URL from which it was downloaded. I went there and got a version number and file name, and confirmed he was running the most recent version available from that site. He also told me that now that I mentioned it, the only folks who'd reported freezing were the folks for whom he'd included the special button. So I knew it had to be the culprit. Time for some searching. Several people claimed that control had a "memory leak" problem. What's more, the developer of the control had released a newer version, which hadn't been mirrored over to the URL our guy found it from.

I told him all this, he went and got the newest version of the control, built the solution, and indeed the GDI count is now well behaved, and no-one has been able to make the application crash, freeze, or hang ever since. (I sat on this story for a few months to be sure.) So there you go, problem solved! I wouldn't have thought it was possible when we started. The moral for me is to use all the tools you have, and to use them fully. This problem was solved with Task Manager, an insistence on trying to reproduce the problem, and Live Search. Phew!