What!? You're Not Done Yet?

What a couple of weeks. I haven’t gotten as much done on the book as I wanted because of two things, some work with an interesting client, and a new machine. The client work was fun, but I was at their site, which happened to be in Knoxville, TN. It was fun staying with Jeff Prosise and seeing the whole Wintellect Crew. Being a virtual company, I’d never met Justin Smith or Dorothy McBay so it was good to finally put a face to the voices. The only problem I had was that Jeff’s kids are growing a little too fast so it’s making me feel rather old. At least I’m not as old as Jeff! J

On the book front, I sent out the outline to the Review Crew and got some amazing feedback on what I’d originally planned. I’m in awe of the responses. If all I did was the outline review, the book is already 30% better than it was. I can’t wait until the Crew starts ripping into the chapters to pieces.

As my editor at Microsoft Press said that paging is now drastically faster than ever before, I can write chapters out of order. That’s a huge luxury as I’ve been able to work on those things that are, and should remain, relatively stable for the life of the book. That’s why in my last blog entry, I said I was starting on the WinDBG/SOS/ADPlus chapter first, which is actually Chapter 6. By letting the jello settle in Visual Studio .NET, I won’t be “chasing the beta” where I’m stuck waiting on some showstopper bug to be fixed before I can continue.

I’ve done a huge chunk of the WinDBG chapter so far. My approach was to assume that the reader had never used WinDBG, which is a safe assumption given what I’ve seen in the industry. My coverage doesn’t go into all the archane parts of WinDBG such as how to load a source file into the Command window, but concentrates on the key native pieces you’ll need to know to be effective and to get you up speed to using SOS.

In playing with the .NET 2.0 version of SOS, it’s sad to see it’s not up to snuff with the version for .NET 1.0 and 1.1 that comes with WinDBG (it’s in the CLR10 directory on Win32 versions). I have mail into the folks at Microsoft to see when we’ll get parity between the SOS versions. Since I’ve become addicted to commands like “!dh –gen 2” it’s painful to live without them. My assumption is that the .NET 2.0 version will eventually get the full boatload of goodies. If it doesn’t, I’ll be the first to start complaining vociferously.

To get the .NET 2.0 version of SOS loaded into WinDBG, use “.loadby sos mscorwks“, which happens to be undocumented. WinDBG will use the directory of MSCORWKS.DLL as the path to SOS. It works no matter which operating system flavor you use.

Getting my new super computer set up took some time away from the book, but it’ll pay off in the end. (At least that’s what I keep deluding myself with…..). I got a dual processor, dual core Opteron from @Xi Computer with 4GB of RAM. Let’s just say that much horsepower, Visual Studio .NET Beta 2 runs fantastic! I can even run multiple instances at the same time! Be still my wildly beating heart. While you might feel it takes that much machine for Beta 2, the real reason I got it was so I could set up multiple simultaneous VMWare sessions for debugging and testing ASP.NET and Web Services.

So far, the machine’s been running extremely well and I’ve been pleased with my one support call to @Xi. For some reason, they forgot to enable the Software Memory Hole in the Northbridge Chip set BIOS option so XP would only recognize 2.25 GB of RAM. As usual, the motherboard documentation was a waste of paper so I was going nuts trying to figure it out on my own. I called them on a Saturday out of desperation and a senior engineer called me back an hour later and gave me the right setting.

As with any machine like this, it’s essentially made out of fans. Every flat surface internally seems like it has a fan on it. Therefore, it’s beyond loud. I’m going to fix that by buying long cables, drilling a big hole in my office floor, and putting the machine in the basement. That’s a heck of a lot cheaper than buying all the stuff to make it silent. At least the noise gives me an excuse to pretend to not hear my wife. (I gotta be careful. She was the approving authority for this super computer!)

Of course, I had to be the dweeb on the bleeding edge and run Windows XP Pro x64 on it. I was having all sorts of flashbacks to my Windows 3.0 days as I was scouring the web for working drivers. The current nVidia RAID/Chipset drivers from their web site are, in Jeffrey Richter’s words, “poo.” I totally love disk write errors and random reboots. Fortunately, the brilliant folks at Guru3D found some later chipset drivers and they work quite well. The nVidia video drivers seem to work until you play a movie file and you’ll get a random reboot. Word on the street is that they’ll have some new drivers soon.

The other problem I ran into was an application problem. Outlook 2003 crashed in MSPST32.DLL every time I started it. After some spelunking, it turns out that Outlook has a bizarre problem that if you have 4GB RAM or more, it doesn’t like that. It’s a known problem. You’ll have to call Microsoft and get the post Office 2003 SP1 hot fix to work around it. Yes, I was shaking my head on this one, too.

From a .NET standpoint, .NET 2.0 x64 is cool in that it just works. I brought some binaries over compiled for 2.0 on a Win32 machine and they were instantly full Win64 programs. In moving some of my C++ native code utilities over, I was wishing native code was that easy.

In making sure the code I’ve done for the book worked correctly on Win64, I did run into a few things that tripped me up. The first was with my MSBuild tasks I discussed last week. In those tasks, I set them up to look for the tool in their default installation locations. The easy trick is to use the %PROGRAMFILES% environment variable as that points to the “C:Program Files” directory. On Win64, you have two Program Files, “”C:Program Files” and “”C:Program Files (x86).” The former is for 64-bit programs and the latter is for 32-bit. As you’d expect, %PROGRAMFILES% points to the proper “C:Program Files.” That’s a problem when many of the tools we’re using (including Visual Studio .NET 2005) are 32-bit programs. I had to tweak my code to look in both places.

Here’s the snippet of my MSBuild project for calling the Wise for Windows installer so you can see how I solved it:

<WFWIProgramWin32>$(PROGRAMFILES)Wise For Windows InstallerWFWI.exe</WFWIProgramWin32>

</PropertyGroup>

<!– Can’t quite figure out how to embed the ‘(x86)’ into the environment variable.–>

<WFWIProgramWin64>$(PROGRAMFILES) (x86)Wise For Windows InstallerWFWI.exe</WFWIProgramWin64>

</PropertyGroup>

<WFWIProgram>$(WFWIProgramWin32)</WFWIProgram>

</PropertyGroup>

<WFWIProgram>$(WFWIProgramWin64)</WFWIProgram>

</PropertyGroup>

The comment above points out a drawback in the MSBuild approach of using parenthesis on environment variables. I haven’t looked too hard, but I haven’t seen how to shove the “(x86)” piece into the environment variable for MSBuild to recognize it.

The other problem I ran into was eerily similar. For other tools, my Tasks looked in the registry for the tool’s installation directory. When a Win32 program writes to the registry under Win64, it doesn’t go directly to the key. The registry code sneaks it into a Win32 WoW64 area. For example, the SourceSafe installation directory on a Win32 machine is written to “HKLMSOFTWARE\MicrosoftVisualStudio8.0SetupVSVSS.” From the 64-bit MSBUILD.EXE, that key is actually, “HKLMSOFTWAREWow6432NodeMicrosoftVisualStudio8.0SetupVSVSS.”

These are no big deals, just something to keep in the back of your mind to keep your code running spiffy when you start developing on Win64. Based on the news reports, it sounds like most developers will be getting x64/EMT64 machines in the next year so you’re going to be facing it pretty quickly.

The Latest I’m Totally Loving about Visual Studio .NET 2005 Beta 2 (or Win64)

· The debugger works like a dream under LUA (Least User Access) for both native and managed. I’ve had problems with Visual Studio .NET 2003 native debugging with LUA and they are all fixed now.

· VMWare runs great with x64 as the host operating system. Virtual PC doesn’t so I’ve switched.

· My “can’t live without” undocumented editor guide lines are still supported under Visual Studio .NET 2005. I can’t program without a red line in column 72 and 80. J

· WinDBG x64 works just the same and still supports the same fine UI (ahem) as its little 32-bit brother.

Latest Problems I’m Having with Visual Studio .NET 2005 Beta 2 (or Win64)

· I’ve had some strange debugger crashes and hangs in MSVCMON.EXE when doing native x64 debugging. I made sure to send in the gigantic full memory mini dumps generated so they should be fixed for release.

· My beloved 4NT does not have an x64 version yet. That means that any Windows component started from it will be the 32-bit version, not the x64 version. A small annoyance, but when you accidentally start REGEDIT and you are looking at the 32-bit version you don’t get the Wow6432Node entries.

· I’m tired of all the “Load of property ‘FxCopInputAssembly’ failed. The ‘FxCop Input Assembly’ must be under the project folder.” warnings on every .NET compile.

What’s up Next?

· Finish off the WinDBG/SOS/ADPlus chapter

· Start the early book chapters

What!? You’re Not Done Yet?