1. Don’t assume that SSD’s won’t/can’t fail.
2. When buying an SSD, check what controller it uses and then get on Google to see how many data recovery providers claim to support that controller; if you find one or less, buy something else.
3. Or even better, RAID and/or back up SSD’s just like you would HDD’s.
4. In the event of failure, an idle, unpowered SSD can retain its contents for a year or so at least with no degradation (YMMV/don’t test this on any data you care about!).
5. People will eventually figure out how to recover your data, if you give them enough money.
6. Making a filesystem dump of an old Windows install bootable again is probably easier now than it’s ever been.
7. Making an old Windows install (or installer) work with USB3.x and NVMe is nigh impossible.
8. With enough old hardware, several rounds of “musical SSD”, Windows 10 installation media, and sufficient masochism, it can be done.
9. Manually bootstrapping a GPT partition is also possible.
10. Not everyone is courteous enough to warn you when they suggest running commands that will immediately and irreversibly remove all partitions from a disk.
11. Windows no longer seems to care how many times you swap your install between completely different computers.
12. When USPS says “7-10 business days” what they really mean is “3-4 weeks, if you’re lucky”.

Anyhow, major props to ACE Data Recovery for figuring out how to restore data from dead Sandforce drives. And also to Recovery Force, for pointing me in their direction.

Normally scheduled programming of “mostly nothing much” should be resuming shortly.

Matchbook Example "Game", 2x iOS and 2x Android clients

Matchbook is a lightweight and platform-agnostic matchmaking solution, intended for use in mobile applications (think games that require near-real-time, relatively-low-latency, persistent communications between two or more client devices).

At its core is a server component, which provides a JSON-based webservice allowing clients to find, create, and join matches. The server also acts as a proxy/relay when necessary, allowing client devices to tunnel through any firewalls that might exist between them.

In addition to the server component, Matchbook includes prebuilt SDK’s for both Java and Objective-C. These SDK’s are intended to support the development of native applications that make use of the Matchbook webservice on Android and iOS devices, respectively.

I could go on at length, but it’s simpler to just link to the project on Github (Matchbook is open-source, and permissively licensed, naturally):

https://github.com/adam-roth/matchbook

Note that Google is currently building comparable functionality into Google Play, although their realtime communications API is currently only available on Android (iOS support is under development).

And although Apple already has realtime and turn-based gaming API’s for iOS, they natually have no intention of inviting Android devices to the party. Ever.

So let the record show that Matchbook got there first.

Previously if you wanted a free/open-source crash reporting framework for iOS your options were basically limited to QuincyKit, which is a serviceable but basic solution. Sadly, the backing architecture used by the QuincyKit server is not well designed and scales very poorly with the number of crash reports in the system. Once you have around 5,000 you’ll notice the server slowing down significantly, and go much beyond 10,000 that and the system grinds to an unusable halt. With a day or so of database and code refactoring, these scalability issues can be resolved, creating a system performant enough to track millions of error logs or more. But that’s a subject for another time. The point for today is that despite its basic level of functionality and flawed server architecture, there are a few key areas in which QuincyKit blows the default implementation of Jira Mobile Connect out of the water:

1. Automatic grouping of crash reports.
2. Automatic symbolication of error logs.

If you have any experience whatsoever with supporting multiple high-volume iOS applications you will instantly realize that these are features that you want. They might even be features that you want more than annotated screenshots, audio feedback, user chat, or seamless integration with Jira and all the awesomeness that Jira brings. In short, Jira Mobile Connect’s lack of support for these two key features may cause serious developers to pass it over in favor of other solutions.

Without grouping every single crash will be creating a new ticket in Jira that you need to track and resolve. Multiple instances of the same crash will have to be manually flagged as duplicates within Jira. And without symbolication trying to actually map back from an error log to the line of code that caused it is an exercise in futility, or at best, tedium.

In any case, rather than abandon the excellent potential shown by Jira Mobile Connect I decided that instead I would attempt to patch it up and add the missing features myself. It’s all open-source code, after-all, and if the tangled mess of PHP that is QuincyKit server can provide these features then they can’t be that difficult to implement. Unfortunately I had to change too many files in too many different places to show the code here, but if you want the short version of it I was able to implement both grouping and symbolication, and you’re welcome to view the complete diffs on bitbucket:

https://bitbucket.org/aroth_iapps/jiraconnect-ios-iapps/compare/..atlassian/jiraconnect-ios (client/native iOS code)
https://bitbucket.org/aroth_iapps/jiraconnect-jiraplugin-iapps/compare/..atlassian/jiraconnect-jiraplugin (server/Java code)

One interesting side-effect of adding groups was that it became possible for multiple client UID’s to be associated with a single Jira ticket. This had an important implication for feedback notifications/chat in that the reference implementation allowed only a single UID to be associated with each Jira ticket. Since the UID is used for determining what notifications/updates to send to the native client, this restricted update notifications to a single user per ticket. Not too useful if you have a common crash that thousands of users have experienced. The implementation above extends the data model to allow multiple UID’s to be stored against a single Jira ticket, allowing each UID to be updated when new feedback is posted by the developer on a ticket. In essence, implementing grouping also required the implementation of group feedback/chat.

There is one caveat with my server implementation, in that it assumes the existence of the ‘symbolicatecrash‘ utility on the system’s runtime PATH. This means that it will only work if your Jira server is hosted on a Mac, with the proper XCode developer tools installed (and with your application’s .app and .dSYM files copied to the local filesystem). This is of course a requirement regardless if you want automatic symbolication to work on any sort of system; somewhere there needs to be a Mac with ‘symbolicatecrash‘ available. In any case, it is a fairly simple matter to either turn this off or otherwise make it more intelligent, if your Jira server is incapable of running ‘symbolicatecrash‘.

Also note that the native iOS code has been restructured to build a universal iOS framework as opposed to an architecture-specific static library. This is done using Karl Stenerud’s excellent XCode4 Project Template. You will need to install this template in order to actually build the modified code. Or you can just refactor it back to build a static library again, but why would you want to do that?

When using the iOS framework, be aware that you will need to set the ‘-all_load‘ linker flag and also include all the images and nibs in the framework’s ‘/Resources‘ folder as part of your build. You will probably also want to include the ‘JMCLocalizable.strings‘ file in the same folder as well, to provide proper text and labels on Jira Mobile Connect’s UI elements.

Regardless, if you do a lot of iOS development and are already using Jira (like you should be) then I encourage you to check this out. This is the Jira Mobile Connect plugin, now with automatic grouping and error log symbolication.

Apple’s explanation (and seemingly, justification) for this atrocity of a feature is that “content should move in the same directions as your finger”. Now that’s all well and good, except for one thing; there is no “finger” when using a mouse. Touch- and mouse-driven are distinct input paradigms.

Apple is correct in that in a touch-driven system content should indeed track in the same direction as the user’s finger moves. If a hypothetical touch-based interface were ever released which scrolled content in the opposite direction of the user’s finger, then people would say that it was broken. And rightly so. Moving content in the same direction as the touch is the intuitive operating mode of a touch interface.

Similarly, moving content in the opposite direction of the scroll (or more accurately, moving the scrollbar in the direction of the scroll) is the intuitive operating mode for a mouse-driven interface. And it follows that Apple’s mouse-driven interface in Lion is just as broken as that hypothetical touch-driven interface would be. By Apple’s logic scrollbars themselves should also be inverted, tracking from the bottom of the scrollbar to the top as the content scrolls from top to bottom. Confused yet? Apple’s blunder here is that they have conflated mouse-driven input with touch-driven input, without bothering to translate properly between the two.

As an interesting aside, a comparable analog to touch-style scrolling does exist in the mouse-driven paradigm; the drag operation. You’ve probably seen it in things like Adobe PDF documents, and it can also be observed on any scrollbar. In the drag operation you choose an anchor-point, and then that anchor point moves in the same direction that you move, and it all intuitively makes sense. The problem with scrolling using a scroll-wheel is that it has no anchor point from the user’s point of view (they have done nothing to nominate one, and the UI does nothing to indicate that one has been chosen). In the mouse-driven paradigm, scrolling is a distinct operation from dragging, and by conflating the two Apple has broken their interface. At least until they start incorporating a touch-screen into every computer they sell.

If Apple’s position is to be taken seriously, then we must accept that the current cursor position must always represent where the user’s “finger” is. There’s one major problem with that, however. With a mouse and cursor, the cursor never leaves the screen. And if the user’s finger is in constant contact with the screen, then why should there be a separate scroll operation at all? It would logically follow (since mouse-driven == touch-driven and cursor == finger in Apple’s world) that since a touch-point exists, and since it is moving, the content (all of it, everywhere) should simply scroll whenever I move the mouse (all the time, everywhere). But of course that is nonsense, and so is Apple’s “natural scrolling” mouse behavior. The mouse cursor is not a finger, it does not represent a finger, and its location is not where your finger is touching. Mouse-driven and touch-driven are different modes of operation, with different intuitive behaviors.

Thankfully, you can turn off “natural” scrolling and rid your OS of its nonsense. I’ll be happy to turn it back on when my mouse is replaced with a touch-screen display, but until that day comes you can forget about it. Apple, please stop trying to convince me that moving my mouse cursor around the screen is supposed to be the same thing as dragging my finger all over a touch screen. It isn’t, and I’m not stupid enough to be convinced that it is.

Sadly, apart from being difficult to navigate, some of the information on the official ‘UrlRewriteFilter‘ website pertaining to setup and usage of the filter is also incorrect/out of date. This is really quite a shame, because ‘UrlRewriteFilter‘ is an excellent little utility and I’m quite tired of seeing people needlessly running multi-server configurations (typically Apache httpd for static content, and something like Tomcat, Resin, Jetty, etc. for dynamic content) out of a desire to use this-or-that particular module that only works with httpd or (even worse) out of the outdated and no-longer-relevant notion that servlet containers cannot efficiently serve static content. So in an effort to save ‘UrlRewriteFilter‘ from obscurity and an undeserved death at the hands of poor documentation and a shoddy distribution site, here is a complete set of instructions for getting the filter to work in your webapp.

First, you will need to ensure that the ‘UrlRewriteFilter‘ JAR file is on your web-application’s classpath. How you do this will depend upon your build process/how you are constructing your webapp(s), but long story short placing the JAR file in your webapp under ‘/WEB-INF/lib’ will do the trick, and if you’ve spent any time at all working with webapps you probably already have a preferred way of doing this. Alternately, you may want to install the JAR file in your servlet container’s ‘/lib’ folder, particularly if you are deploying multiple webapps on your server and you want to have ‘UrlRewriteFilter‘ available to any/all of them automatically.

In any case, once you have the ‘UrlRewriteFilter‘ JAR on your webapp’s classpath, the real setup can begin. Open your application’s ‘web.xml‘ file, and add the following filter configuration to your webapp:

<!-- URL rewriting -->
<filter>
    	<filter-name>UrlRewriteFilter</filter-name>
      	<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
      	<init-param>
        	<param-name>logLevel</param-name>
        	<param-value>WARN</param-value>
        </init-param>
</filter>
<filter-mapping>
    	<filter-name>UrlRewriteFilter</filter-name>
    	<url-pattern>/*</url-pattern>
</filter-mapping>

This instructs the servlet container to route every request that the server receives through the ‘UrlRewriteFilter‘. Note that although it is not discussed on the official site, that ‘logLevel‘ parameter is absolutely essential. If you omit it, the filter will fail to initialize properly and yield some very bizarre behavior.

Anyways, once your ‘web.xml‘ has been updated, the final step is to add a ‘urlrewrite.xml‘ file in the same directory as your ‘web.xml‘ file, and configure it to your liking. Here is an example ‘urlrewrite.xml‘ file with a couple basic rewrite rules:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
        "http://tuckey.org/res/dtds/urlrewrite3.2.dtd">
<urlrewrite>
    <!-- user-account activation link -->
    <rule>
    	<from>/activate/([a-f0-9]+)?(.*)</from>
     	<to>/userController?action=activateUser&amp;token=$1&amp;$2</to>
    </rule>

    <!-- default rules included with urlrewrite -->
    <rule>
        <note>
            The rule means that requests to /test/status/ will be redirected to /rewrite-status
            the url will be rewritten.
        </note>
        <from>/test/status/</from>
        <to type="redirect">%{context-path}/rewrite-status</to>
    </rule>
    <outbound-rule>
        <note>
            The outbound-rule specifies that when response.encodeURL is called (if you are using JSTL c:url)
            the url /rewrite-status will be rewritten to /test/status/.

            The above rule and this outbound-rule means that end users should never see the
            url /rewrite-status only /test/status/ both in thier location bar and in hyperlinks
            in your pages.
        </note>
        <from>/rewrite-status</from>
        <to>/test/status/</to>
    </outbound-rule> 
</urlrewrite>

This defines two rules. The first simply rewrites URL’s of the form ‘/activate/######?[params]‘ to something like ‘/userController?action=activateUser&token=######&[params]‘, and the second is the default example rule that comes with ‘UrlRewriteFilter‘ and allows you to see a basic diagnostic page by pointing your browser at ‘[your server]/test/status‘.

And there you have it. Quite simple, really, and now there’s one less reason to continue running two distinct server instances where one would do just as well.

Long story short, my feelings toward Portal 2 are a bit mixed. Viewed as a game in its own right, Portal 2 does not disappoint. It’s really hard to find much to fault it for in this context. But viewed as a continuation of the original Portal, the game just doesn’t quite live up to the sky-high expectations that I (and probably other fans of the original game) had for it. GLaDOS is back, and just as sarcastic, humorous, and passive-aggressive as ever. At least for the first half of the game. Something seems to happen to the writing about halfway through; it loses its clever wit, that special something-or-other that left you anticipating the next catty remark from GLaDOS and laughing-out-loud when it finally arrived.

Much of the dialog towards the end of the game becomes just matter-of-fact moving-the-story-along chatter, with one AI acting loopy and another AI trying to provide a plausible explanation for why the first one is acting loopy. After a certain point, it just doesn’t feel as clever. At first I thought that it might be just because your antagonist changes, but that’s not really it. Wheatley’s early game dialog is on par with anything GLaDOS ever said, but as the game progresses his lines become less and less inspired. By the time you reach the end some of them are so bland that you pretty much have to force yourself to listen.

In the end, I think the developers erred in putting too much effort into trying to explain and justify their game world. Why should I care about history when there is a sarcastic, witty, and antagonistic AI practically goading me into dismantling it? Such was the case in Portal, but unfortunately not so in Portal 2. Instead the game distracts itself in trying to explain the origins of its world and the players within it, and the result is that some of the drive to keep pushing forward is lost.

Moving along, Portal had its fair share of fiendishly difficult levels. Levels which would leave you genuinely stumped and probably kill you once or twice before you puzzled your way out of them. Portal 2 has a couple of moderately challenging levels, but for the most part the puzzles are straightforward and easy to solve. I’m glad that for the most part the developers fixed it so that going through a portal won’t arbitrarily rotate your character’s orientation (and/or they made it easier to avoid placing portals such that they force you to rotate), but apart from that I think the game was nerfed a bit too much.

Portal put you on a conveyor belt heading towards an incinerator and left you with very little time to work out an escape plan. The situation felt very tense the first time through, and if you did not react very quickly to locate the way out then the game had no qualms about killing you for your shortcoming. Portal 2 has a similar scenario, but the way out of it is much too obvious and the element of danger just isn’t there. Rather than being compelled to react, it feels like there’s plenty of time to just stand their and listen to the AI gloat about its triumph. The sense of imminent danger just isn’t there like it was in the original game.

That said, there’s very little to complain about in terms of graphics, sound or gameplay. Any reviewer who gripes about Portal 2 (PC version, obviously) suffering from being a “port of the console version” is just being a fool. Portal 2 was implemented using the Source engine, an engine which began its life first and foremost as a PC game engine. It cannot be a “port” of anything if its implementation engine natively supports the PC as a target platform.

Yes the graphics in Portal 2 are a bit simple/dated-looking, but such has been the case with every Source-engine game released (even the very first games to use the engine). Valve has always favored attaining playable framerates on lower-end hardware over throwing in lots of hardware-crushing eye-candy, and I’m not about to fault them for their decision. If you need hardware-crushing eye-candy, play Crysis.

On top of its solid graphics and gameplay, Portal 2 gives you quite a few new puzzles to play through. In fact, there are almost certainly more puzzles in the Portal 2 single-player game than in Portal’s single-player game. But, because of the decreased level of difficulty, most of these new puzzles can be breezed through in a handful of minutes, even on your first play-through. It took me less then 7 hours to complete the single-player game, and I wasn’t rushing or trying to solve puzzles as quickly as possible.

I spent time exploring the environment and looking around, trying to knock off as many achievements as I could, and still I only needed 7 hours to complete the game. That’s a bit short, but the problem isn’t that the game itself is too short, rather it’s that the level of difficulty has been reduced too much. Once you know the solutions, Portal can be completed in far less than 7 hours. Portal 2’s real problem is that too many of the solutions are a bit too obvious.

Portal 2 does introduce a number of new gameplay elements, from the propulsion/repulsion/conversion gels, to mirrored “discouragement redirection cubes”, to hard-light bridges, excursion beams, and “aerial faith-plates”. The last of these I find a bit questionable, as their real purpose seems to be replacing some of Portal’s more challenging jumps (the ones where you have to work out some way to build sufficient momentum to bridge an impassable chasm of some sort or another) with a prepackaged solution that “just works”.

Unlike the gels, mirrors, bridges, and beams, the aerial faith-plates function less as a tool for solving the current puzzle and more like a quick way of hopping between Point A and Point B without using a portal and without having to worry about where you land. I think the game could have been better without them, but apart from that I also think that the rest of the new gameplay elements function very well within the context of the game, and I’m surprised that Valve was able to come up with so many new physics things to add to the game.

One last thing that leaves me a little confused is the decision to replace the guided missiles of Portal with generic unpropelled exploding boxes in Portal 2. It doesn’t really change the gameplay that much, but personally I found the missiles to be a lot more threatening and fun than some nondescript red boxes that just happen to explode when they hit something. Perhaps Valve decided that they didn’t want to renew their missile targeting AI license?

Anyways, though I have picked the game apart over a few minor issues, I still think that overall Portal 2 is a very fun game and worth a play-through or two. Play it and enjoy it as a game in its own right, as its biggest flaws only become apparent when you hold it to the candle that is Portal the first. It doesn’t quite satisfy as a sequel to that original magical title, but as a first-person puzzle game with a completely unique mode of gameplay there’s still nothing else quite like it.

Overall score: 8.5 / 10.0

P.S. The Portal Song is an order of magnitude better than The Portal 2 Song. So don’t get your hopes up expecting an epic musical ending like in the first game. You still get a musical ending, but it’s not quite as epic.

Each comic in Webcomix is periodically checked for updates, so if like me you keep tabs on several different web-comics that all update at different intervals then Webcomix will save you from having to remember to refresh half a dozen different websites at various times just to keep up to date. Simply visit your Webcomix dashboard and you’re set!

Underneath the covers there’s a fair bit that I’m proud of with this app. First off the entire system is designed to be as lightweight and efficient (in terms of server compute-time and bandwidth) as reasonably possible. Virtually all of the actual work is handled by the client-side JavaScript. The handful of tasks that must be performed server-side are optimized with the help of a custom caching layer which ensures that any given computation (or fetch of an external resource) only needs to be performed once. There is also an additional caching layer in the client used to prevent it from making any given request to the server more than once per session.

The server itself is client-agnostic and provides a simple JSON-based API, meaning that while the initial incarnation of Webcomix is in the form of a web-app it should be just as easy to package the same functionality in a mobile, desktop, or other flavor of application. But that’s a project for another day.

Anyhow, please note that Webcomix should be considered to be beta software at the moment. So if you find any bugs or have any suggestions for new features or improved functionality then please don’t hesitate to say so in the comments section.

Also, the list of comics currently available in Webcomix is not set in stone and is only based upon my personal preferences at the moment. Webcomix is designed in a way that makes adding additional comics a trivial task, so if your favorite comic is currently not in the list then I encourage you to post a request in the comments section so that I can add it.

Lastly, if anyone has any good ideas for how to extend the comic selection UI to handle a large number of comics that they’d like to share, then please do. The current interface with its basic rows of checkboxes is obviously not sufficient for handling hundreds (or even dozens) of comics. It needs to be replaced with something better (or at least, collapsible) soon.

No other news to report at the moment, I just wanted to publicly show my support for this excellent WordPress plugin.

Update: Much as I still love this plugin, it did introduce a pretty severe layout bug in Internet Explorer (any post with a code block in it would be stretched beyond the width specified in the theme layout, causing the posts to overlap with the right-nav section). I fixed this by adding the following to my IE stylesheet:

.entry-content {
	width: 100%;
}

And while we’re on the subject, the image lightbox plugin also did not work correctly in Internet Explorer by default (the background overlay was solid black instead of translucent). I had to add the following CSS to get it working (again in the IE-only stylesheet):

#stimuli_overlay {
    display: none;
}

Note that this completely removes the background overlay. I could probably get the alpha set correctly without too much more fuss, but I think this works well enough for now.

To my fellow web-developers, I can only say the following: I know it’s fun to dump on IE for its lack of standards compliance, poor performance, and other failings, but at the end of the day IE is still the most used browser in the world, so it behooves us to always test our work in Internet Explorer when authoring online content or when authoring any code that will be used to generate online content.

Homegroups allow for much simplified sharing of multimedia and other content between computers on a network. There is very little explicit configuration needed, and when an application integrates with the Homegroup properly there is really no noticeable difference between a local resource and one that’s being streamed from some other computer on the Homegroup. This makes for a very cool experience when it all works, and in Windows Media Player it works seemlessly. My media library can be distributed across several systems, and yet from each one I can access the entire volume as if it is all local to that particular machine. And it just works, flawlessly, with no onerous setup or manual cajoling needed on my part. This is what good software is supposed to do; merge invisibly into the background so that the user can accomplish a complex task as if by magic, and currently only Windows Media Player does it.

I’m sure that situation will change in the near future, but at the moment its seamless Homegroup integration makes Windows Media Player the only media player that I am interested in using. And that means that some of its other shortcomings, such as a complete lack of support for a variety of free and open codecs and file formats, need to be dealt with. Now there are a number of tutorials on this subject already, but many of them give inaccurate or incomplete information. In the interest of having a complete set of instructions that actually work, if you want to enable FLAC/Vorbis/etc. support in Windows Media Player, do the following:

1. Install the DirectShow filters/codecs.
2. Install the Tag Support plugin.
3. OPTIONAL: If, like me, you included your FLAC folders/files in your library before installing the above packages, then you also need to rebuild your Windows Media Player library. Make sure you close Windows Media Player and shut down its network sharing service either by stopping it under ‘Control Panel -> Administrative Tools -> Services‘ or by killing the ‘wmpnetwk.exe‘ process in the Task Manager before attempting to delete or rename its configuration folder.

And that’s really all there is to it. You may or may not end up with the ability to seek within and/or see the duration of FLAC files. I’ve seen it happen both ways on occasion, it seems like it either works or not depending upon the mood that Windows Media Player happens to be in when these plugins are installed. But the important bit is that all the previously unsupported files will now show up correctly in your library, and also (of course) that they are now playable.

And in other news, the rebuilding continues, slowly.

Now back in the day, I would use a nifty little SourceForge project called phptriad to handle all of the little installation and configuration nonsensicalities for me.  Phptriad was quick, easy, and generally worked straight away.  There’s just one major problem with it; the project hasn’t seen any updates since September 9th of the year 2000.  Using it nowadays consigns one to hopelessly outdated versions of Apache and PHP (and also MySQL). Versions that are so hopelessly outdated that they do not meet the minimum requirements for running WordPress.

So I decided that this time around I would do things the correct way, and install the latest version of Apache, the latest version of PHP, and then configure them to talk with each other.  “How hard can it be”, I recall myself saying.  The PHP installer even had an Apache configuration step that seemed like it would handle the entire process automatically.  But sadly that was not the case; the automatic configurator did nothing useful, and while the configuration process was not hard it was exceedingly poorly documented and circuitous, turning what should have been a 2-minute task into a nearly 2-hour endeavor.

Now, do a quick Google search for Apache and PHP configuration issues and you will find countless posts suggesting adding minor variations of the following directives to Apache’s httpd.conf file:

AddHandler application/x-httpd-php .php .phtml
AddType application/x-httpd-php .php

Seems like a simple enough fix, but none of the myriad variations of these two directives did the trick. It makes sense when you think about it, considering that all these directives do is associate .php files with a MIME type. Left wide open is the question of how Apache is supposed to know what that MIME type actually means, how it should be handled, and where to find the handler. Yes, the php5_apache22 module is being loaded as well, but the module isn’t magic; Apache still needs to know when and how it should use it. So essentially what’s missing is a mapping to tell Apache “for MIME type ‘x’, use program ‘y'”. After far too much searching, I found a page that also mentioned adding the following directive:

Action application/x-httpd-php "/path/to/your/php.exe"

And finally there was the missing piece. The AddType (or if you prefer, AddHandler) directive associates .php files with a particular MIME type, and the Action directive maps that MIME type to a concrete resource that Apache can use to process items of that type. Apache now knows both what a .php file is, and how to process it, and like magic the server behaves as it should. All told far too much digging was needed to uncover that one critical line.

For reference, the complete PHP configuration section in my httpd.conf file looks like so:

PHPIniDir "~/apache/php"
LoadModule php5_module "~/apache/php/php5apache2_2.dll"
AddType application/x-httpd-php .php
Action application/x-httpd-php "~/apache/php/php.exe"

I suspect that the actual MIME type assigned to .php files matters very little here, so long as the type is consistent between the ‘AddType’ directive and the ‘Action’ directive.