Come quick, Watson! File a report on yourself!

This is a pre-RC2 build of Vista, and the particular bug has already been fixed, but it still makes me laugh.

Advertisements

Python gets right what Java already has, and .NET still hasn't

In the Java world, you have the base type of java.lang.Throwable, and the subclasses of java.lang.Error (you basically never catch this, at least not in application code) and java.lang.Exception (this you can use to your heart’s content).

In .NET, for various reasons (and yes, I’ve had threads internally about this, including with Chris), there’s no such split of the hierarchy.  There’s the base type System.Exception.  There’s also a subclass called ApplicationException, where the idea was that we’d do our exception split there with a SystemException and ApplicationException split.  However, even we couldn’t keep that straight, so now even we consider it useless.

Why bother bringing this all up now?

Because it looks like Python 3.0 is going to get it right.  They’re doing what I think .NET should do at this point – give Exception a new superclass.  Is it trivial?  No.  Will it break existing source?  Yes.  Is it the right long-term answer?  I think so.

http://www.onlamp.com/pub/a/python/2006/10/26/python-25.html

In addition to the deprecation of raising strings as exceptions, Python 2.5 also rearranged the exception class hierarchy. The new BaseException class is the base class for Exception. You should now derive all your custom exception classes from Exception, or from a class derived from Exception.

Two other exception classes, KeyboardInterrupt and SystemExit, also extend BaseException, but not Exception. Thus, you can trap your own exceptions, and then trap all other exceptions derived from Exception. This will trap every exception except KeyboardInterrupt and SystemExit. Why would you not want to trap those two exceptions? That way your program will end when the user presses Ctrl+C without you having to manually catch and respond to Ctrl+C, or without you having to manually skip catching Ctrl+C to let the system handle it. The same is true with the SystemExit exception, which should force the program to stop.

This particular new feature, then, is less of a feature and more of a requirement: Recode your exception classes to extend Exception. Then you’ll be fine when Python 3.0 arrives.

RDP v6 client (the one in Vista) no longer allows saving credentials to the RDP file

Another little useful XP thing I find gone in Vista is the ability of the terminal services client (mstsc) to save credentials (user/pass) to the RDP file.  In particular, in the RDP file the “password:” entry would be written hashed (presumably with something about the machine as the salt, since it doesn’t work on other machines, but I’ve never dug into it)

Where you used to have a username and password set of text boxes (and could then save these to the RDP file), you now just get a notification that you will be prompted.  Tellingly, the size of the “Logon settings” group box is the same, so you have a big empty gray area to remind you of the functionality lost.

It’s worth noting that the client still respects the RDP files written by earlier clients, though, so if you can get that password: entry written by something other mechanism (*cough*) then you’ll still be fine.

This is one of those places that highlight that usability and security exist on opposite sides of a gradient.  Will security be a bit better now that the common user won’t be able to save their credentials to RDP files?  Probably, but now the client’s a little less usable for many people.  C’est la vie.

XP's web publishing wizard is gone from Vista

One of the XP features I (and Jessica) used a good bit was the (extensible) web publishing wizard.  In particular, we used Gallery2’s support for it to publish albums directly from the windows shell (explorer).

http://codex.gallery2.org/index.php/Gallery2:Modules:publishxp

Unfortunately, this handy little thing has been removed from Vista.  There’s no equivalent functionality in the shell, either.  That sucks.

Using the new MemoryFailPoint

This is an interesting concept.  It doesn’t help much for TFS since most of the time we don’t have any idea how much data is coming back from SQL until it’s too late, but I could see it being useful in lots of other scenarios 🙂 

You allocate a MemoryFailPoint for X megabytes of memory, where X is an upper bound on the expected additional working set for processing one request. You then process the request, then call Dispose on the MemoryFailPoint. If not enough memory was available, the constructor will throw an InsufficientMemoryException, which is a different exception type we created to express the concept of a “soft OOM”.

Source: BCLTeam’s WebLog : CLR Behavior on OutOfMemoryExceptions [Brian Grunkemeyer]

Turn on wake-on-lan in Vista

Now that Vista is out and defaulting to “hybrid sleep” (sleep then hibernate… it’s a very nice and eco-friendly default power setting), those of us that have machines we routinely need to connect into remotely need to enable our network cards to be able to wake up the machine.

Now, I don’t claim to be an expert in Wake-on-LAN by any means, but turning it on is pretty simple, and then TS connections (tcp port 3389, assuming default port) and ping’s (icmp echo’s) both seem to wake up the machine fine.

 

Open NIC config

– Start -> control panel -> network and sharing center -> manage network connections -> rclick / properties on the network device

Turn on Wake-on-LAN

– Configure -> power management -> allow this device to wake the computer

Earthlink now 20% more evil – adopting SiteFinder tactics

Remember with VeriSign did a Very Evil Thing and decided they wanted to resolve all non-resolvable addresses via their SiteFinder service?  Looks like Earthlink wants to do the same thing (I didn’t catch this the first time it went around, apparently), although admittedly scoped to only their users (or, well, people using their DNS servers to be more specific).

I was curious whether Google’s codesearch (available at http://www.google.com/codesearch) was also available via http://codesearch.google.com/ so I gave that a shot in Firefox.  I quickly got redirected to… wait for it…

http://earthlink-help.net/?d=error_earthlink-bf&q=codesearch.google.com

Even better, the page actually never loads – my status bar is stuck at “Waiting for my.earthlink.net”

Some quick searches shows it’s been going on for ~6 weeks now.  Here’s some background

I love some of the comments, who apparently realize the same as I do:

This is not a feature, guys, and you’re fooling nobody. Those leeches at VeriSign tried this already, but gosh, for some reason they stopped. I wonder why. Spare yourselves this.

If it ain't broke, then break it

Sorry, but Shaq is right.

 

That thing is basically (outside of the channel diffs) today’s indoor-outdoor ball.  I love a league that claims to hate carries coming out with this under the guise of helping grip… and then all the feedback talks about how it’s more slippery than the last ball once it gets wet (and if you’ve seen a game, there’s a bit of moisture coming off the players).

Spalding must be spawning.  I’m expecting Coke Classic within a few months.