Worst Microsoft Dialogs

So, I thought this dialog was pretty bad:

I mean, the only question in all that text (you know, the sentence that ends in a question mark) is not a yes/no question.  The actual question is down at the bottom and ends in a nonsensical colon.  And it has not one, but two parenthetical phrases.  And it contains a really long, unwieldy URL that isn't clickable or copyable.

But then I got this gem from Windows Live Mail (in Windows 7) today:

First of all, I had pressed ALT+F4 to close WLM having completed my business with it.  Opening a modal dialog for something only tangentially related to exiting the app is a little intrusive, but, okay.  The thing that's really bad about this is that it tells me what won't happen if I click yes, but I still have no idea what will happen if I click yes.  But I only use WLM to read mail that comes to my passport account from Microsoft lists, so if it all gets deleted I don't really care.  So I'm feeling adventurous and click yes.  Then I get this:

Really?  You didn't see that one coming WLM?

Sigh.  The fight goes on.

Perforce has the best error messages.

I wanted to know what the path to something was on the server, but I couldn't remember. Little did I know that perforce would be so judgemental:

c:\source>p4 dirs *
//depot/foo/bar/baz
//depot/foo/bar/qux
Client map too twisted for directory list.

And then there was the time I made a perfectly reasonable request, I wanted to edit all the unittest files in the entire tree, and it had to go and get all preachy:

c:\source\v2-dev>p4 edit foo\...*unittest.cc
Senseless juxtaposition of wildcards in '//jeff-src/foo/...*unittest.cc'.

I mean, yeah, maybe there's a typo there, but you don't have to insult me.

GetModuleFileName() on OS X.

So, you want to know the path to your module.  On Windows, it's easy: you call GetModuleFileName() and pass NULL for the HMODULE.

But what if you're trying to do it on OS X?

#include <dlfcn.h>
std::string GetModuleFileNameOSX() {
  Dl_info module_info;
  if (dladdr(reinterpret_cast<void*>(GetModuleFileNameOSX), &module_info) == 0) {
    // Failed to find the symbol we asked for.
    return std::string();
  }
  return std::string(module_info.dli_fname);
}

For the first param to dladdr, you can pass any symbol you know will be in your module. In theory, something similar should work on linux, but I haven't tried.

Adventures in Diffing...

So today Schneier recommended AVG as a useful, free anti-virus solution. As I'm terribly anti-virus, I wanted to see if really ran "...in the background, automatically, and you won't notice any performance degradation at all." So I installed it. My first step was going to be comparing the registry before and after the install to see what sorts of things it was installing. This is where my experiment took a left turn: I just wanted to view the diff.

c:\Users\jeff\Desktop>dir *.reg
Volume in drive C has no label.
Volume Serial Number is 96A6-6911

Directory of c:\Users\jeff\Desktop

11/10/2009 09:18 AM 487,799,220 registry-after-install.reg
11/10/2009 08:53 AM 487,588,198 registry-before.reg
2 File(s) 975,387,418 bytes
0 Dir(s) 220,934,803,456 bytes free

Turns out the registry is frickin' huge! Whatever AVG did, it added about 211k of goop to the registry.

My first attempt was to use my favorite diff tool, windiff.exe. Windiff has been my trusted companion ever since I joined MSFT back in 2001. Today, for the first time, it let me down. After churning on the files for about two minutes it ran out of memory.

Very sad.  So, next we tried gnu diff from the command line.  Gnu diff allocated some memory, then allocated some more, and, in a manner much quicker than windiff, proceeded to give me garbage output because it doesn't believe in unicode.

I also tried P4Merge, but it knew its limitations.

In a last-ditch effort to get the info I wanted, I turned to the Mac.  FileMerge on OS X 10.5 (so, the 32bit version) failed as well.  It churned for awhile, the crashed with no clear reason, but I suspect it was out of memory.

So, my little experiment failed.  What did we learn from all this?  The Windows Registry is too large, I think.  Or, just trust Bruce.

Things I Hope Are Fixed In The Next Version

Exporting from the registry to disk happens on the UI thread. I hope this is fixed in regedit in Windows 7.

Loading symbols (from disk or the public symbol server) happens on the UI thread. I hope this is fixed in Visual Studio 2010.

I'm holding my breath.

a trip to the Microsoft company store...

I was recently in Redmond and one of my good MSFT friends was kind enough to take me to the company store to pick up a copy of VS2008 and Vista. As we strolled through the lobby, we saw this:




And later on, inside the store proper, we saw this:




My friend, who is a PM for User Experience related things in the Windows team just sighed and said, "why does it gotta be this way?" And I laughed.

But it is easy to make fun of Microsoft for failing in their own technology showcase, but I've learned two things:

1) All software is pretty terrible when you get down to it.
2) Programming is hard.

Both machines are using Windows in a way that was not the primary concern of anyone who was working on Windows Vista. Developers tend to focus on the use cases they expect--users at home, users at work. But as computers become more general purpose, we have to start thinking through a bunch of other scenarios as well. Heck, I bet someone even knows how to configure these machines to prevent these things from happening, but I couldn't tell you how to do it.

Adventures in Driver Updates

I love that Windows Update brings me the latest drivers for my video card. It's too bad that hardware OEMs still can't figure out how to write installers. The engrish is amusing as well:



At least Windows Update thinks it succeeded.