Balint's Blog

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.