This month I’ll cover not a defect so much as a challenge to an initial assumption, but for end users it sure feels like a bug. BoundsChecker needs to support a lot of Windows platform and Visual Studio IDE combinations. The 10.x line covers all the way from XP through Vista up to Windows 7, and all equivalent server platforms with service packs. When we planned and implemented the new 64-bit application support shipping in 10.5, we consciously focused on Win 7 and Vista and the Server 2008 versions, and we omitted adding support for XP SP2 x64. We did not believe many people adopted XP SP2 x64 simply because it was perceived as an immature version of an x64 OS and uptake was not widespread. We didn’t add XP SP2 x64 to the documented support matrix though we did explicitly add the newer OS versions, and we also did not add any scary documentation or engineering restraints to prevent people from trying to use BC on XP SP2 x64. So like any assumption that goes wrong, 10.5 shipped and several customers almost immediately started providing feedback that XP SP2 x64 application support in BC did not work fully, despite that Analysis and Code Review worked fine.
So we were faced with a quandary: do we force people to upgrade and only support them on the more recent platforms and strictly adhere our current OS plus one back policy, or do we dig in, bust the policy, and provide XP SP2 x64 support. It turned out all we needed was an incremental addition to our process hooking logic. That bit of sleuthing only took a few days of engineering, is a relatively repeatable process for any platform release, and could be tested quite directly and simply. We decided therefore to add XP SP2 x64 into the upcoming 10.5.1 point release, alongside changes for Win 7 SP1 and VS 2010 SP1, and cover those customer requests to run on XP SP2 x64 and 2003 R2 SP2 x64.
Philosophically, this behavior shows off two items. First off, this wasn’t a bug: it was a non-requirement and a semi-documented limitation. How well we enforced this non requirement is debatable, whether it was kinder to put in blocker restraints or just roll the dice that it might have “just worked” was a risk we took. Secondly, by remaining agile and listening to actual customer feedback, we are able to quickly turn around and provide this capability. For the small sliver of installed base that still runs on XP SP2 x64 and cannot drop that platform for whatever their reasons, we wanted to ensure they could use DevPartner without paving their development station to get it. In truth, people use DevPartner for years and years after release, so extending the product backwards into old platforms often yields an even longer time window to reap the benefits of using it.
What brings this home on a personal note is very clear: my day to day desktop station happens to be XP SP2 x64. I can finally run BC locally without running VMs or RDCing into a Win 7 or Vista host, or dragging out my nice but underpowered Win 7 laptop. Yee haw!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.