Take a look at this map from Jeff LaPorte:

I wonder if this shows some sort of era-of-adoption effect, where folks in the US had widespread Internet access so they got started with AIM and never switched, then Canada and Australia picked up Messenger, and other places see a popularity of even more recent clients? Or perhaps it’s an artefact involving what kind of people use a messenging-interop solution? Whatever the mechanism, I’m a typical Canadian I guess since I use Messenger.

Kate

Whenever an application blows up and offers to send information to Microsoft, please please say yes. On Vista it’s described as “checking for a solution” to make it more obvious what’s in it for you.

Sometimes, when you send this information to the giant Windows Error Reporting mother ship, you get a response that your blowup was caused by a known problem, and a link you can click for more information. That doesn’t happen to me very often, which I guess means I am among the first to find problems in shipping software. But that doesn’t mean you can’t benefit from the fix when the developers finally get around to acting on the reports they get from the WinQual program. Here is something you should do every month or so if you can remember.

First, bring up Problem Reports and Solutions. It’s on the control panel, or just click Start and type Problem, then press enter. You’ll see something like this:

Click View Problem History on the side. You will see a list of stuff that has blown up on your computer over the months.

Interesting, isn’t it? Click the Select all box at the top, and also Check Again For Solutions to Other Problems. Now click the Check for Solutions button. It will go and have a think:

It might also ask you if it can send extra info for some blowups, I always say yes. In for a penny in for a pound eh?

Then, the cool part. New solutions!

Click a link and you’ll get some more info with a link straight to the page that lets you get the update or latest version or whatever that specifically fixes the problem you had on your computer.

You can clear your problem history, but I am not sure why you would. You never know when a fix will show up for a problem you already had.

Kate

Check out http://www.easyduplicatefinder.com/  - it has tracked down all the identical demos, powerpoints etc all over my C drive in quite a short time. I haven’t let it do the deleting yet, but the finding is worth a lot to me (I can delete for myself once they’re found.) Three gig of duplicates and that’s without looking on the networked shares where I store things when I’m done!

Kate

The guys call me a regular now, and I suppose I am. Here’s another hour of rambling and fun covering Vista (especially the Vista Bridge) the Vista things you’re not allowed to implement in managed code, C++, the MFC update, concurrency, and whatever else popped into my head while we were talking.

KateP>

Imagine you have a bug that happens only in production. You connect to the production server and do a whole pile of exploring, and now you think you know what you need to tweak on your dev box to reproduce the problem and get started on fixing it. Or perhaps you are half way through figuring something out on your own machine and you need to hand over to another developer. Maybe you just want to switch to your laptop because you’re leaving the office. There are many reasons why you might want to copy breakpoints between computers. As you may know, they are kept in a .SUO file (Solution User Options I believe) in your solution folder.

But heavens above, do not try to copy that file from one machine to another! As John Robbins says:

The .SUO file is the bane of your existence. Nearly all the problems you encounter with Visual Studio are the result of a corrupt .SUO file. Sadly, it seems all it takes to corrupt the .SUO file is your heart beating. In other words, whenever you have Visual Studio crash, refuse to debug, or behave strangely it's the .SUO file's fault. Whenever anyone asks me about strange Visual Studio behavior, my instantaneous response is "Delete the .SUO!"

So John took care of this with his own add-in. You can save a set of breakpoints into a little file. You can then move the file between machines and use it to set all those same breakpoints on another machine. Or, probably even more fun, you can set aside the 20-some breakpoints, tracepoints, conditionals and so on that you painstakingly set up for bug A, save them and then clear them all, set different ones for the drop-everything-urgent bug B, and then when B is fixed you can get all your old breakpoints back and return to working on A. John is giving the add-in away, it works for both native and managed code, so go on, get it now.

Kate

One of the persistent myths of managed code is that you can’t have a memory leak if you’re a C# or VB developer. You really can. In this intriguing post, Sasha Goldshtein asks "Is it a managed or a native memory leak?" and then shows you some clues to lead you towards an answer.

Kate

While I was at Tech Ed Developers (US) this summer, I spoke with Craig Shoemaker for his Pixel8 podcast. We talk about UI, and Vista, and the usual things. I have some distinguished company in this interview but if you don’t want to listen to Ted Neward you can zip ahead to the 18 minute mark for me.

Kate

In case you were worried that Microsoft efforts like the Parallel Framework (PFX) would be aimed only at managed developers, leaving native developers sitting at the little kids table again, take a look at the Parallel Programming in Native Code blog. It hasn’t been updated terribly often, but perhaps some feedback would encourage them (or is it just Rick?) to keep it current . The one downer: "this is technology we're currently exploring and I don't have any ship or CTP dates to announce." Stay tuned, I suppose.

Kate