Shrink the size of the VMWare guest desktop icons

I use VMWare on a daily basis to debug basis.   While my host OS is run with two monitors set at their highest resolution, I typically run the guest OS at 800x600.  This way, the guest OS only occupies part of one of the host monitors making it easy to drag and drop files from the host onto the guest desktop.

As a result of all this dragging and dropping from the host, the desktop of my guest OS is typically littered with icons for test applications, utilities etc.  Unfortunately, with a Windows Vista guest the icons can be rather large and rapidly fill the available area.

Recently, there was a post on The Old New Thing blog that provided a solution to my problem.    The post describes two ways to change the size of the desktop icons on Windows Vista:

• Click on the desktop, then hold the Control key while rotating the mouse wheel.
• Right-click on the desktop and choose an icon size from the View menu.

For Windows Vista guests, at least, I can just scroll down the size of the icons to a size appropriate to an 800x600 desktop.  Problem solved!

VMWare Shared Folders and Sysinternals FileMon

I use VMWare on a daily basis to develop, test and debug.  I also use tools from the Sysinterals suite on nearly a daily basis.  Today, I ran into a gotcha with respect to VMWare shared folders and Sysinternals Filemon.

If you open a file using the shared folders UNC path (as describe here) FileMon won't see the file operations.  Fortunately, the more recently updated Sysinternals Process Monitor behaves as expected.

Sysinternals Live is Live

I have no idea how long this has been available but today when I was updating my Sysinternals suite on my development system I noticed the following on the Sysinternals home page:

Sysinternals Live

Sysinternals Live is a service that enables you to execute Sysinternals tools directly from the Web without hunting for and manually downloading them. Simply enter a tool’s Sysinternals Live path into Windows Explorer or a command prompt as http://live.sysinternals.com/<toolname> or  \\live.sysinternals.com\tools\<toolname>.

You can view the entire Sysinternals Live tools directory in a browser at http://live.sysinternals.com.

This certainly wouldn't be the way one would choose to run ProcMon on a daily basis but in a pinch if you're debugging an issue on a test machine it's certainly useful.

Debugging a Service on Vista with VMWare Virtual Debugger

Note to self about using the VMWare Visual Studio Integrated Virtual Debugger to attach to a service running on a VMWare Vista guest OS --

If you get the message similar to "Failed to attach to process" as below:

Don't forget to do the following in the Vista guest OS:

1. Turn off firewall
2. Add logged in user to Administrators group
3. Disable User Account Control (UAC) by clicking "User Accounts" on the Control Panel, typing "user" in the search box and then clicking "Turn User  Account Control (UAC) on or off".

Fool me once shame on you Vista, fool me twice  shame on me -- I should have written this down the first time!

Taxonomy of Exceptions

Eric Lippert offers an interesting taxonomy of exceptions:

Fatal exceptions are not your fault, you cannot prevent them, and you cannot sensibly clean up from them.  [...]

Boneheaded exceptions are your own darn fault, you could have prevented them and therefore they are bugs in your code. [...]

Vexing exceptions are the result of unfortunate design decisions.  [...]

And finally, exogenous exceptions [...] are the result of untidy external realities impinging upon your beautiful, crisp program logic.

When I worked on DevPartner Fault Simulator (now unfortunately discontinued) we dealt with understanding these kinds of exceptions both in code Fault Simulator analyzed and in our own code.

As Eric points out,  writing good error handling code is hard in any language, whether you have exception handling or not.  I see far to much code that either simply ignores return values or overly aggressively catches exceptions.  Eric's taxonomy is a useful way to think about how your code should handle (or not) error conditions.

Go Large Hadron Collider, Go!

I've got to say, I think today's Google homepage image is awesome!