Diamondback: Method 'VirtualPC.CommitSomeStuffAndRollOtherStuffBack' not found #Delphi

So my first try didn't go so well. I still don't know why — problem with Diamondback? problem with Virtual PC? problem with the Registry? problem with the stuff I checked or didn't check during installation? No clue. But on my second attempt to install Diamondback and compile our code base, I decided to be a little smarter about the whole process.

Step 1: I made another copy off our master "clean Windows XP" virtual hard disk, and created a new virtual machine. Then I called IT (before I installed Diamondback) to join this new machine to our domain. (Once again, Matt was over within five minutes. Our IT people are awesome.) Then, I shut the VM down and saved a copy of the virtual hard drive. Now, if I need to start over and reinstall Diamondback again, I can start from this snapshot, and not have to pull Matt over to this end of the building again. I hate bugging people when I don't have to.

Step 2: Install Diamondback inside the VM.

Step 3: Shut down the VM and enable undoable disks.

This is an awesome feature. While the VM is running, anything it writes to its "hard disk" isn't saved directly back to the virtual hard-drive file on the host. Instead, the changes are written to a separate log file. Then, when you shut the VM down, you're asked whether you want to permanently merge the changes into the virtual hard drive, or throw the changes away.

Since I suspected that something in my installation and/or Registry got hosed last time, this feature is perfect. Just put the program files on one virtual hard drive, and enable undo on that drive. And put my source files on another drive without undoable support. That way, whenever I want to reboot, I can revert my Program Files and my Registry to their original, pristine state; but any code changes I've made for Diamondback compatibility, and any .bpls and .dcps from any packages I've already compiled, remain untouched. Beautiful.

Can't do it.

It turns out that Virtual PC's "undoable disk" checkbox is per virtual machine, not per drive. You can't make virtual drive C undoable and drive D not undoable. You can't commit one drive on shutdown and revert the other, either. There's no UI for it. They simply never thought anyone could use that feature, so they didn't put it in.

I'm pretty sure that VMWare does let you make some disks undoable and some not. And I actually do have a license for VMWare back at my desk. But what I don't have is a ready-made VMWare virtual hard disk with Windows XP already installed, and installing an OS in a VM takes a long time. Sigh.

Okay, Virtual PC can't do what I want through this feature alone. Might it be possible through some combination of features? If Virtual PC can do it, then that's considerably easier than installing VMWare and starting from scratch.

Well, yes. They can do it. They have a feature called "shared folders" (I think VMWare actually had this feature first) where you pick a folder on the host, and map it to a drive letter in the VM. Since those files aren't on the virtual hard disk, they won't be undone. Fits the bill. But it actually operates using Windows file sharing, on the VM side at least, so you'd be taking a sizable speed hit. Viable, but it's worth looking into other possibilities first.

They have one other feature that looks promising: you can have the VM talk directly to a physical hard drive on the host computer. Combine that with an undoable drive, and you get nirvana. And we had a spare partition with almost nothing on it. I cleaned it out and tried to point Virtual PC to it. But it only showed me one available drive, and I could only set that one up as read-only.

I hunted around a little more before I figured it out — when they say they connect to a hard disk, they mean a hard disk. Not a partition — an entire physical hard disk. This machine had multiple "drives" in multiple partitions, but they were all sitting on the same piece of hardware. And since that hard drive was in use by the host OS, Virtual PC said, "No, you ninny, I'm not going to let you have two OSes writing to the same hard drive at the same time. That would be stupid."

Fair enough.

I checked with IT, but they were fresh out of spare hard drives. I thought about running out and buying one over my lunch break, but decided against it.

I decided on the shared folders. I suspected that they would be slow, but decided to follow the Rule of Optimization: actually measure the performance before you decide it's too slow.

And the speed actually was, to a point, okay. The speed isn't what killed shared folders as an option. Ah, no. They got a little more creative than that.