While test driving Windows 7 RC I suddenly needed to run a virtual machine to avoid dual booting to access a few key applications that could not survive the combination of an x64 platform and Windows 7. Either one on its own would have been fine but the combination was lethal. Killing two birds with one stone I felt the time was right to test drive the Windows Virtual PC beta and Virtual Windows XP. The first day I managed to completely ruin my XP virtual machine and had to start over. This was the start of a healthy dose of stupidity tax in combination with a rather opaque interface to the virtual machines which still only dented the superb first impression slightly.
The user interface is a custom Explorer folder, supposedly containing actions for creating and managing virtual machines. Not so in my case, despite reinstalling twice, I only have a fancy icon in the toolbar and that’s it. No actions avaiable. This doesn’t hamper proceedings much, though as I can still double click a virtual machine file (*.vmcx) to start it. How do I create a virtual machine, though? Google tells me that to create a new virtual machine I type vmcwizard.exe in the start menu search field and press enter. Google is right. Once created, you configure the machine by right clicking the file in the explorer and clicking Settings. Here you get a properties box that has more in common with Windows Server 2008 and Hyper-V than with Virtual PC, which is of course great.
The integration features make the VM able to talk to USB devices on the physical computer aside for the usual disk, printer, clipboard and sound integration also available. In order to run old (or just badly made 32-bit only) applications virtually you look at the Auto-Publish tab and enable that feature. This means that application shortcuts under the All Users Start Menu end up published in the host-OS Start Menu under All Programs –> Windows Virtual PC –> [Virtual Machine Name]. Any notification icons displayed in the virtual machine while it is running in application mode will also be forwarded to the host OS notification area. To enable this, you may be wise to store credentials for a user account on the VM that has proper authorization to run the programs installed. This way the integration becomes seamless.
Virtual Windows XP is thus just a preconfigured Windows XP SP3 image with auto-publish checked. Nothing magical that you couldn’t make yourself provided you had a spare license for Windows XP, obviously.
The user experience while working with Windows Virtual PC is excellent compared to old Virtual PC 2007, because it feels just like Hyper-V for 2008 even though Hyper-V has superior performance to Windows Virtual PC, allegedly.
Problems? Oh yes. The virtual Windows XP wants to update itself through Windows Update. After it does, the virtual machine is Initializing, only showing a progressbar that suddenly starts over. After X number of iterations, I found, on non-Microsoft parts the Internet again, the shortcut Shift+Esc which shows the console instead of the progress bar. Lo and behold: Windows XP was BSOD:ing so the VM was rebooting continously! Not surprising since it’s XP, but it still is annoying since I’ll have to recreate my VM again which is boring. A utility which salvaged VM:s killed by Windows Update would be a nice-to-have trinket.
Also, integration just stops working in a few cases, and there is no way of forcing it on without tens of thousands of reboots which may or may not have the desired effect. No indication from either guest OS, host OS or VM player what the problem is. These things are extremely frustrating and could so easily be avoided.
I have a few design guidelines for Working Software, note that these are completely diametrically opposed to guidelines for security and stability, but this is for those of us who need to actually work for a living:
- Never check for preconditions before you try something*
- Never use locks. Don’t have shared write access to global resources, dummy.
- Unless you risk actually destroying something valuable**, never mind errors, just continue.
- Incorporate DDoS code to punish non-responsive servers. This is the only way.
- Automatically kill processes locking the file you need. Those processes are never vital, statistics say***,
*90% of the case your check will be overly pessimistic, especially if you check version numbers. They are always a bad idea
** This is the case in less than 0,1% of production code. Mostly you get corrupt data which is, again, important in only a small percentage of the cases. Like I wrote initially, this is not for the people looking for correct or secure software, only software that delivers.
*** This claim is completely bogus. I mean the percentages above were complete fabrications as well, but this one tops them all.