STLport on Visual Studio 2005

As part of my effort to port to VS2005, I updated to the latest version of STLport, 5.1.0. I've now reconsidered this and have switched to the STL built into VS2005. Here's why.

Years ago, when I initially switched from MFC collection classes to STL, I ran into one big problem - STL didn't have any debugging code to check iterators or array bounds. This caused random mysterious failures in the field in my first product that used STL when I didn't understand that certain operations invalidated iterators. I spent months working the problems out of that product. As part of that effort, I switched to STLport, which was much more robust than the STL implementation in Visual C++ 6.0 and STLport had debugging code in it to trap invalidated iterators, invalid array bounds, and other such programming errors.

The version of STL that ships with VS2005 benefits from Microsoft's security push and has had code added to check for problems like invalid array bounds. The VS2005 STL also has extensive debugging code that goes away in the release build. So my original need for STLport has ended. Even so, since my code was already thoroughly tested with STLport, I thought it best not to switch.

Today I was enduring my normal frustrations trying to debug an STLport set, which is effectively impossible to view in the debugger. I had the same problem with STL collection classes in VC6. Then I discovered that the VS2005 debugger actually understands the version of STL that ships with VS2005 and will automatically display the elements in collection classes such as set and vector. This is a huge timesaver and was enough justification for me to drop STLport.

Update 12/18/2007: A set of debugger visualizers has been published for STLport. Go to this link.

ReadyBoost Problems

I've had to disable ReadyBoost on my system. I've been using the Apacer HT202 Handy Steno 1GB drive, which at a 200x transfer rate is supposed to be one of the best drives on the market for ReadyBoost. I've run this configuration for two weeks now and have consistently run into the same problem. After using the system for several hours with dozens of windows open, the thumb drive hangs. It's not clear whether the drive itself hangs or whether it's a driver issue, but Vista is not able to recover. Explorer hangs, the DOS prompt hangs - anything that tries to access the drive locks up and can't be killed in Task Manager.

A hardware reset brings the system back to normal, except now the RAID array is unhappy because it's been interrupted and it takes two hours to validate the mirror, during which time the system is unusable. (Intel ICH8R chipset on a P5b Deluxe WiFi motherboard.)

Hopefully a solution will present itself after Vista is released to consumers.

The Windows SDK

If you want to use many of the new features in Windows Vista, you'll need to load the latest Platform SDK. Except it's no longer called the Platform SDK, it's now called the Windows SDK. You can find it at:

http://www.microsoft.com/downloads/details.aspx?familyid=7614FE22-8A64-4DFB-AA0C-DB53035F40A0&displaylang=en

This link points to the final release. Make sure you don't download one of the Release Candidates instead.

Using the latest SDK is a bit of a challenge. It's an all-or-nothing proposition because of new security tags that have been added. Once you've installed the SDK (1.2GB!!) you'll need to update Visual Studio 2005 to make it work. Go to Tools / Options / Projects and Solutions / VC++ directories and add the following:

• Add C:\Program Files\Microsoft SDKs\Windows\v6.0\bin to the list of directories for Executable files. The new entry should be above ALL of the VCInstallDir entries.
• Add C:\Program Files\Microsoft SDKs\Windows\v6.0\include to the list of directories for Include files. The new entry should be above $(VCInstallDir)PlatformSDK\include.
• Add C:\Program Files\Microsoft SDKs\Windows\v6.0\lib to the list of directories for Library files. The new entry should be above $(VCInstallDir)PlatformSDK\lib.

I also use STLport and the Boost library. I put the STLport and Boost directories at the top of the list. I then had to add #undef __in_range before including any STL files in order to make STLport build with the new SDK.

Finally, if you run into an error such as this one:

C:\Program Files\Microsoft SDKs\Windows\v6.0\Include\unknwn.idl(108) : error MIDL2025 : syntax error : expecting ] or , near "annotation"

This error is caused by using the Visual Studio 2005 MIDL compiler instead of the Windows SDK midl compiler. The Windows SDK midl compiler is thirteen months newer. The fix is to add the SDK bin directory to the list of directories as described above. Thanks to Mike Wasson for describing this fix in this article.

(Revised 12/27/2006)

Visual Studio Debugger Hangs

Ever since I first tried to run our software under Visual Studio 2003, I've had trouble with the debugger and the debuggee freezing solid. This problem cropped up again today in Visual Studio 2005. I knew the problem was something to do with the symbol server, but that was all I knew. Fortunately, the developer of VirtualDub has pinpointed the causes. You can find his discussion at:

http://www.virtualdub.org/blog/pivot/entry.php?id=118

The easiest solution to the second problem in the article is to "seed the cache." Visual Studio shows in its status bar (at the bottom) which DLL is being processed. In your application startup code you need to call LoadLibrary for each DLL that causes a hang, as shown in that status bar. This will force Visual Studio to download the symbols over the Internet while the process is in a "safe" state.

In my case, on a Windows Vista RTM system, I placed the following code in InitInstance() before any network calls were made:

LoadLibrary("SENSAPI.DLL");
LoadLibrary("SCHANNEL.DLL");
LoadLibrary("CREDSSP.DLL");
LoadLibrary("RASAPI32.DLL");

Note that these aren't all of the DLLs, just the DLLs at the top of the dependency hierarchy. The dependent DLLs will be loaded automatically. It's not a bad idea to just leave this code in your debug build because the problem will recur as soon as any of those DLLs are updated in a service pack. Make sure you add the related "FreeLibrary" calls if you do this.

Parallel Builds - Success!

I've given up on the parallel build facility in VCBUILD (the /M option, such as /M2). It is almost useless for our build scenario. Instead I've switched to GNU make from the "cygwin" project. GNU make supports the -j command line parameter to enable parallel builds. GNU make also allows me to specify dependencies at whatever granularity level I need. Currently I specify dependencies on a per-project basis (one project = one .vcproj file), but I could just as easily go one level deeper and have multiple dependencies for each project, such as Debug/Release/Demo.

My makefile looks something like this (simplified for demonstration purposes):

all: sdk gui server

sdk:
vcbuild c:/proj/sdk/sdk.vcproj

gui: core
vcbuild c:/proj/gui/gui.vcproj

server: core
vcbuild c:/proj/svr/svr.vcproj

core:
vcbuild c:/proj/core/core.vcproj

This makefile is launched by a batch file that sets two very important environment variables:

set SolutionPath=c:\proj\proj.sln
set VCBUILD_DEFAULT_OPTIONS=/M1

By setting the "SolutionPath" environment variable to the solution file, we give VCBUILD the ability to set the $(SolutionDir) variable in the build scripts, which is typically required to build successfully.

When you point VCBUILD at a vcproj file, it automatically builds all configurations in that file. This way the makefile doesn't need to have knowledge of all the possible configurations. One feature you give up by specifying the vcproj file is that VCBUILD won't automatically add dependent libraries to the link line. For Visual Studio, this isn't a loss because the feature is largely broken anyway.

Using GNU make gives me the control that I need to keep my dual core processor busy. I'm finally happy :-)

Parallel Builds

One of the features in Visual Studio 2005 that I was most looking forward to was the ability to do parallel builds such that both cores in the Dual Core processor are used. So far this has been a complete bust.

Problem #1: Visual Studio wants to build based on Configurations instead of Projects. This means that you can't build a Release version of a project at the same time you build a Debug version.
Problem #2: Visual Studio will only build one Configuration at a time. This means that you can't create a build of one product while another product is in progress.
Problem #3: The meaning of Problem #1 and Problem #2 is that Visual Studio is optimized to build solutions that are based on many projects. This is typical for a C# application, but somewhat atypical for a C++ application. Our build hierarchy is wide and shallow, which means that Visual Studio's parallel build mechanism is almost useless.

I also tried to create a fake configuration that included all projects. This solution didn't work either because many library dependencies are generated based on the configuration, and this information is lost with an all-at-once Configuration.

VS2005 SP1 Released

Service Pack 1 for Visual Studio 2005 was released on December 14. I thought this would cure my VS2005 Vista-related issues, but now Microsoft is saying that there is going to be a service pack for the service pack that will address Vista compatibility. This update will be called the "Visual Studio 2005 SP1 Update for Windows Vista" and isn't expected to be available until February or March.

Here are links for SP1 for VS2005:

• MSDN page for Visual Studio 2005 SP1: http://msdn.microsoft.com/vstudio/support/vs2005sp1/default.aspx
• Download site for Visual Studio 2005 SP1 for Standard, Professional and Team editions: http://www.microsoft.com/downloads/details.aspx?FamilyId=BB4A75AB-E2D4-4C96-B39D-37BAF6B5B1DC
• Download site for Visual Studio 2005 SP1 for Express editions: http://www.microsoft.com/downloads/details.aspx?FamilyId=7B0B0339-613A-46E6-AB4D-080D4D4A8C4E
• Download site for Team Foundation Server SP1: http://www.microsoft.com/downloads/details.aspx?FamilyId=A9AB638C-04D2-4AEE-8AE8-9F00DD454AB8