The Laptop LoJack sample will be hosted on Codeplex, here. Actually, I’m having problems connecting to their TFS server this morning, so the initial code will be available later in the day.

What does the sample do? It currently consists of two components. The first is a Windows 7 location sensor driver (based on the User-Mode Driver Framework – no kernel-mode code here). The driver uses your public IP address to determine latitude and longitude coordinates.

What does that mean? It means that this project turns your laptop into a GPS, without having to buy an actual GPS – pretty cool! Not only that, but the GPS capability is exposed in the new “proper, platform-compliant” way, so that any Win 7 applications that are location-aware can use it.

Big disclaimer, though: unless you live in a major city, the granularity is regional at best. Why is that? The trick I use to obtain the coordinates is simple: local search on Microsoft Live Maps. That is, when you connect to the default URL for Live Maps, the returned page includes script goop that supports local search. That goop includes default lat & long for wherever the server thinks you are, based on your IP address. (As an aside, there’s another clue that the server is doing a reverse look-up on you, even before you run an actual search: when the default map loads, notice how it’s centered on your region!)

That process of mapping an IP address to a physical location, known as IP geocoding, is imprecise. In fact, it’s only the big technology providers like Google/Microsoft/Yahoo that can afford to maintain the most up-to-date IP geocoding databases; their incentive to do so is competition for search traffic. Once the Laptop LoJack code is live, I’m hoping to get additional user feedback on how accurate your location data is.

So, the sensor driver for Laptop LoJack is screen-scraping its coordinates from Live Maps. This is not an ideal implementation. For example, if Live changes the names, or even just whitespacing, in the script embedded in that default page, the screen-scraping code will break. Plus, since the sensor is UMDF, I really didn’t want to use the .NET framework in-proc, even though loading and robustly parsing the page might be easier that way in the long run (instead, I used WinHttp and some of the string library routines in the CRT).

That said, the code works, and the concept is cool. Next steps? We need to design and implement a cool (WPF-based) viewer application for the location data. We also need to provide a (WiX-based) MSI for this, because installing the UMDF driver by hand is painful. Stay tuned …

1 Comment »