# Friday, September 12, 2008

Vista gets a lot of bad press it doesn’t really deserve. For example, it crashes way less than XP for me. Some applications behaved oddly at first (primarily because of UAC and Virtualization) but I have either learned workarounds, such as running the app elevated, or upgraded or replaced the apps that were causing trouble. The slow file copy thing drove me insane, but SP1 took care of that. I really have very few complaints left about my computer, and the ones I have are aimed at specific applications (yeah, Outlook 2007, I am looking at you when I say that, and Adobe, don’t think not meeting my eyes will keep you out of my bad books) rather than the operating system.

Still, who wouldn’t want to make their operating system run faster and smoother? Here are some helpful thoughts and guides:

Windows Vista Performance and Tuning. A downloadable paper from Microsoft. Simple stuff here like choosing the right power management plan, using ReadyBoost, tweaking your search settings, and so on. Worth a read.

Vista Annoyances Resolved. Despite being annoyingly spread over 9 pages (see what taking ads does to you?) it has some good stuff. You’ll see explanations of SuperFetch, ReadyBoost, restore points, and more.

Roundtable with Mark Russinovich. An upcoming special roundtable on Vista Performance. Send your questions in ahead of time, then tune in for answers.

Learn a little, enjoy your daily computing life more.


Friday, September 12, 2008 7:21:46 PM (Eastern Daylight Time, UTC-04:00)  #    
# Thursday, September 11, 2008

The Tech Ed Online folks have kicked off a Women in Technology page. They’re aggregating blogs, videos, news, profiles and more. Take a look around – I’ve added it to my favourites.


Thursday, September 11, 2008 10:23:01 AM (Eastern Daylight Time, UTC-04:00)  #    
# Wednesday, September 10, 2008

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.


Wednesday, September 10, 2008 10:19:43 AM (Eastern Daylight Time, UTC-04:00)  #    
# Tuesday, September 09, 2008

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.


Tuesday, September 09, 2008 10:14:33 AM (Eastern Daylight Time, UTC-04:00)  #    
# Monday, September 08, 2008

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!


Monday, September 08, 2008 10:05:35 AM (Eastern Daylight Time, UTC-04:00)  #    
# Sunday, September 07, 2008

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.


Sunday, September 07, 2008 10:03:39 AM (Eastern Daylight Time, UTC-04:00)  #    
# Saturday, September 06, 2008

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.


Saturday, September 06, 2008 10:01:09 AM (Eastern Daylight Time, UTC-04:00)  #    
# Friday, September 05, 2008

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.


Friday, September 05, 2008 9:58:05 AM (Eastern Daylight Time, UTC-04:00)  #