Balint’s Blog

Having recently upgraded to Visual Studio 2008, my lackluster experience with developing and debugging native code in the ‘improved’ IDE has left me looking (and I am still) for hotfixes that might patch various painful problems. In particular, the IDE suffers major performance problems when debugging large C++ projects that (believe it or not) have breakpoints set. With a little experimentation I discovered that actually have any breakpoints at all causes a massive performance hit when single-stepping through one’s code, whether or not they are disabled. This is not a good thing for a debugger and it’s GUI, which is a real shame since Visual Studio 2005 was not plagued by any such issues.

This leads me to the following idea: why not keep using the Visual Studio 2005 IDE for development and debugging, but make it use the VC 2008 compiler and newer libraries (i.e. MFC 9 and the VC++ 2008 redistributables)? This will mean that Visual Studio 2005 will build your projects with the newer compiler and link to the latest versions of the runtime/MFC/etc. Since the 2005 debugger will work for either version (i.e. 2005- or 2008-compiled code), one can safely revert back to Visual Studio 2005 for such simple activities as single-stepping (phew!). I must point out that one good think Microsoft did for Visual Studio 2008 was dramatically improve their performance analysis tools – this would be the only reason to use the 2008 IDE: the newer profiling tools/GUI.

The first thing to do is to identify the full path of Visual Studio 2008’s ‘VC’ directory, and where version ‘6.0A’ of the Platform SDK resides. By default they are (respectively):

C:\Program Files\Microsoft Visual Studio 9.0\VC
C:\Program Files\Microsoft SDKs\Windows\v6.0A

Next you need to create a property sheet that contains the necessary information for a VS 2005 C/C++ project to use the 2008 headers and libraries.
Create a new property sheet file manuall (e.g. “VS9.vsprops”) and insert the following, adjusting the paths where necessary:

<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioPropertySheet
 ProjectType="Visual C++"
 Version="8.00"
 Name="VS9"
 >
 <Tool
 Name="VCCLCompilerTool"
 AdditionalIncludeDirectories="&quot;C:\Program Files\Microsoft Visual Studio 9.0\VC\include&quot;;&quot;C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\include&quot;;&quot;C:\Program Files\Microsoft SDKs\Windows\v6.0A&quot;"
 />
 <Tool
 Name="VCLinkerTool"
 AdditionalLibraryDirectories="&quot;C:\Program Files\Microsoft Visual Studio 9.0\VC\lib&quot;;&quot;C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\lib&quot;;&quot;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib&quot;;&quot;C:\Program Files\Microsoft Visual Studio 9.0&quot;"
 />
 <Tool
 Name="VCResourceCompilerTool"
 AdditionalIncludeDirectories="&quot;C:\Program Files\Microsoft Visual Studio 9.0\VC\include&quot;;&quot;C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\include&quot;;&quot;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include&quot;"
 IgnoreStandardIncludePath="true"
 />
</VisualStudioPropertySheet>

Then in Visual Studio 2005, open the Property Manager (via the View menu), and add this new file. Make sure in the Project Settings, under General, the property “Inherited Project Property Sheets” includes the new file.

The last trick is to add the following paths to the “Executable Files” list in VS 2005 under Tools -> Options -> Projects and Solutions -> VC++ Directories:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin
C:\Program Files\Microsoft Visual Studio 9.0\VC\bin
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE

The first is for RC.exe, the second is the compiler and the third is for the linker to find DLLs for manipulating debug information (e.g. mspdb80.dll).
NOTE: They don’t have to be added at the very top of the list (e.g. the NASM directory might be at the top) but they must come before the VS 2005-versions of the same directories. That is, they should come before the following since they are supposed to override them (that said, you shouldn’t have to remove any entires if the order is correct):

$(VCInstallDir)bin
$(VSInstallDir)Common7\Tools\bin
$(VSInstallDir)Common7\ide

Also, note: once you put these new paths in, ALL projects compiled under VS 2005 will use the VC 2008 compiler and tools. Unfortunately there is no clean way to override the compiler/tool paths using the VSProps method above. I tried creating a user-defined macro in the VSProps named ‘VSInstallDir’ to override the in-built one, but it had no effect. Although I haven’t tested it, there shouldn’t be a problem if you use the new compiler on VS 2005 projects without the inherited VSProps – you’ll just have a newer compiler linking to MFC 8 and the VC 2005 runtime, which shouldn’t (hopefully) cause any dramas!

I host my own mail server (Courier with Spamassassin) and check my mail via IMAP on my iPhone. Unfortunately Apple never implemented use of the IDLE command to enable Push with an IMAP account (there is a jailbroken app that will do this!), so the alternative (if one is desperate for Push) is to pipe their email to a service that is supported (Yahoo, and now apparently Gmail), or set up Microsoft Exchange. Me, being me, I decided to try something new, and set about setting up Exchange. The first step, of course, is installing Windows Server (I decided to do a fresh install of 2008 Datacenter Edition), setting up a domain controller/forest/domain, and then Exchange, which I actually installed on another machine that runs Windows Server 2003 R2. The only issue is that Microsoft has not release a supported version of Exchange Server 2007 for 32-bit x86 machines! The only option is their 64-bit build, and as I don’t have any 64-bit server machines (my servers are a tad old) I had to make do with Exchange 2003 with Service Pack 2 (SP2 includes the additional functionality to enable Push, specifically ActiveSync).

After it all appeared to be installed and happy, my iPhone would not beep, no matter how many emails I sent myself. As it turns out, the entire time (of course) it was connected to my WiFi network. As soon as I disabled WiFi on the device, and it connected to my server via the 3G network, I noticed the “IP-AUTD Initialized” message in the server’s event log. Hurrah!

The reason? Have a look at point #2 in: iPhone 2.0 software: Troubleshooting iPhone or iPod touch Exchange ActiveSync “Push” issues (thank you very much to Tonicwater, see below). Perhaps the iPhone could check for a network environment change (i.e. logging on a WiFi network) and flush the DNS cache – at least for mail/corporate-related activities, such as the address of one’s registered Exchange servers. Then they would always be current, and the ‘push’ process could be re-initiated with the same server at its newfound address.

The final step was to forward mail from my Linux mail server to Exchange. This was accomplished by adding the following code to the end of Courier’s maildroprc file:

if ($LOGNAME eq "(my Courier email address)" || $USER eq "balint")
{
  cc "!(my Exchange email address)"
}

I also added an Exchange recipient policy so that it would only keep the last 30 days of messages, which doubles as a backup of sorts.

Here is a useful page to help with diagnosing problems with Push in Exchange: http://msexchangeteam.com/archive/2006/04/03/424028.aspx

After upgrading my Drupal site to the latest point release (5.19), before transitioning to version 6, I discovered that the action parameter of all rendered forms were being prefixed a slash ‘/’. This in itself is reasonable since one would expect the REQUEST_URI server variable to return a relative URL. However, as I host several websites, Drupal runs inside its own VHost with URL rewriting to enable short URLs (without the ‘q=’ querystring). If I access Drupal directly via the web server’s address, which maps to the default VHost (this also happens to be Drupal), REQUEST_URI is relative. If I access it via the address externally visible on the web (http://spench.net/) then REQUEST_URI is absolute (i.e. prefixed with the protocol and domain).

The Druapl ‘request_uri’ function in includes/bootstrap.inc always adds a slash to the beginning of the server variable REQUEST_URI, which will break any absolute URLs.

The following modification (the strpos check) resolves this issue:

/**
* Since $_SERVER['REQUEST_URI'] is only available on Apache, we
* generate an equivalent using other environment variables.
*/
function request_uri() {
  if (isset($_SERVER['REQUEST_URI'])) {
    $uri = $_SERVER['REQUEST_URI'];
  }
  else {
    if (isset($_SERVER['argv'])) {
      $uri = $_SERVER['SCRIPT_NAME'] .'?'. $_SERVER['argv'][0];
    }
    else {
      $uri = $_SERVER['SCRIPT_NAME'] .'?'. $_SERVER['QUERY_STRING'];
    }
  }
  if (strpos($uri, '/') == 0)
  {
    // Prevent multiple slashes to avoid cross site requests via the FAPI.
    $uri = '/'. ltrim($uri, '/');
  }
  return $uri;
}


When debugging my VC++ projects, I routinely make use of ‘Edit & Continue’ by modifying code in the Visual Studio environment while stepping through the compiled code. Recently I found that typing into a code window would cause Visual Studio to become unresponsive for a long period. Checking Task Manager, I found that WerFault had kicked in and was generating a minidump for DevEnv.exe – Visual Studio was clearly not happy. The unusual thing was that Visual Studio would not immediately terminate after the minidump finished. Instead, it would continue running. However, if I would now close the debugee (my own application), attempt to continue execution with modified source code (which would activate Edit & Continue), or manually stop the debugger, Visual Studio would crash.

After a very thorough search (looking at Visual Studio’s stack trace using symbols from the Microsoft Symbol Store, seeing exceptions thrown from HeapFree and IDebugEncLineMap, un-installing various plugins such as AnkhSVN, and duplicating the tests on another machine), I could not identify the cause. Thinking about any configuration changes I had made in the last months, I tried removing the all additional Include & Library paths I had ever added to the VC++ directory options. These can be found (on Vista) in:

C:\Users\User Name\AppData\Local\Microsoft\Visual Studio\8.0\VCComponents.dat

Voila! No more crashes! As it turned out, I had added so many extra Include/Library directories (each with a long path) that some portion of the debugger would crash when reproducing the steps described above. Perhaps this is a buffer overflow? I had a look through the patch listing on Microsoft Connect, but found nothing matching this problem.

Now, I wanted to have my cake and eat it too: I resolved this issue, while keeping all of my configured Include/Library directories, by creating a hard-link (or NTFS reparse point) to the base of my SDK directory (under which all of the Include/Library directories reside) further up the directory chain, in effect shortening the path lengths.

For example, here are two Include directories:
C:\Documents and Settings\User Name\My Documents\Visual Studio 2005\Projects\_SDK\Some Code\include
C:\Documents and Settings\User Name\My Documents\Visual Studio 2005\Projects\_SDK\Other Code\include

Lots of these will crash Visual Studio.
They both share the parent: C:\Documents and Settings\User Name\My Documents\Visual Studio 2005\Projects\_SDK

So create a reparse point at: C:\Dev\SDK And make it point to the parent above.

So now in Visual Studio, you can change the original Include directories to:
C:\Dev\SDK\Some Code\include
C:\Dev\SDK\Other Code\include

In total, they are of a much shorter length and fall under the mysterious buffer limit, thereby avoiding the dreaded crash scenario.

NTFS soft/hard-links can be made using the command-line tools at the bottom of this handy page.