Diamondback vs. Virtual PC #Delphi

To continue our saga:

So I had Diamondback installed inside Virtual PC, on an undoable disk. Every time I rebooted, I threw away the changes, making exceptions only rarely (to set environment variables, etc.) My source files were on an E: drive, which was mapped to a C:\Joe directory on the host (and which was therefore not subject to the undo). So far so good.

Then I tried to get latest code from VSS. But when I tried to set my working directory, VSS didn't even list the E: drive in the "Drives" dropdown box. (Yes, Drives. Not "Look In", not folder tree. "Drives" combo box. We're talking the classic Windows 3.1 File Open dialog.) It's not at all clear why the E: drive wasn't there, since it does list our F: drive, which is also a network drive. But I eventually coerced it into accepting it (by typing "E:" and hitting Enter). If that didn't work, I always could have hacked the VSS.INI file.

(Isn't that scary? VSS still puts its settings in an INI file, still uses a Windows 3.1-style File Open dialog, still uses a buggy owner-drawn listbox instead of a proper treeview. And Microsoft still sells this thing.)

Anyway, I got the working directory set, and started getting code. And it took a long, long time. I eventually figured out that I was better off running VSS on the host PC, rather than running it inside the VM; if I got files into C:\Joe\VSS instead of into the VM's E:\VSS, it made for something like a 2x-3x speed improvement.

Speed improvements are always nice, but it's a bit of a pain not to be able to reliably Alt+Tab between VSS and Delphi. I can Alt+Tab into Virtual PC, since it's just another application on the host. But once I'm there, I can't Alt+Tab back out, because Alt+Tab is then handled by the virtual OS. Workable, but irritating.

Once I had the code on my mapped drive, I went into Diamondback and, once again, started compiling packages. The speed here was not bad. What was bad were the crashes.

And the weird thing was, it usually wasn't the compiler that was crashing, nor was it the IDE (though both crashed once or twice on me). What kept crashing most consistently was the File Open dialog.

I would get a few packages compiled, and then I would go to open another one, and sometimes, when I double-clicked on a folder, I would get a nasty error message. (I apologize for not having screenshots, or even remembering the actual error messages, but it's been over a week ago that I went through all this, and I'm just now getting it blogged.) At one point, Diamondback actually closed (no error, no save prompt, nothing) while I was in the Save dialog. Now, that's a nasty crash.

And I was racking my brain, trying to figure out what on earth Borland could be doing that would make the File Open dialog crash. This was truly weird. But it only happened every two or three packages, so I kept going. And rebooting the VM often. And undoing its hard disk religiously.

I eventually realized that the problem occurred most often when I double-clicked on a folder with lots of files in it. So I started typing in the relative path and filename, and hitting Open, without ever actually browsing to any of the offending folders. The shell's AutoComplete sometimes helped me here; I would type the folder name and a backslash, and it would start prompting me with some of the matching filenames.

Then I got to the TMS component pack. They had, by far, the largest number of files of any package I had yet compiled. And I could not get their package opened. AutoComplete, I suspect, had become my enemy: whatever background thread was looking ahead, scanning for files in the directory I was typing in, would crash before I could type the entire path. That's just a guess, though, because if I assembled the entire path in Notepad, copied it, and then did a rapid-fire paste-and-Open, it would still crash more often than not.

As I was wrestling with this, I got a really big clue as to the problem... when Windows Explorer crashed.

The problem never had anything to do with Diamondback. The problem was with the way Virtual PC maps those drives. Somewhere between the Virtual PC Extensions and Windows XP, somebody was dropping the ball. Big-time. And crashing the entire host application.

As it turns out, that, and not the simple fact of it being a network drive, was why file accesses on that E: drive were so slow. (The F: drive was never slow from inside the VM. I know, because that's where our VSS repository is, and getting files to the C: drive inside the VM was just as fast as getting files to the C: drive outside the VM.) And that's why it was usually the File Open dialog, and not the IDE, that was crashing. The occasional times that the compiler or IDE did crash, I suspect, were when Diamondback tried to open a file and Virtual PC said, "I'm tired of getting files for you. Why don't you just leave me alone?"

What had seemed like a promising option was a no-go. I ain't gonna use a filesystem that crashes whenever I try to list files.

So... scratch one more option. On to plan C (or was it D? E?)