I see that I’ve used the phrase “open mouth, change feet” a number of times in the life of this blog to describe the continuing ability of Microsoft to snatch defeat from the jaws of victory. Today I came across yet another example.
I had noticed some reports that people weren’t able to get their navigation software to interface with the GPS sensor built in to some Windows 8 tablets.
Now the thing is that until very recently, PCs did not have GPS hardware built into them. Instead, external devices such as GPS Data Loggers were used to provide GPS data, and interfaced to Windows software applications via Windows COM (communications) ports. In the old days, these were physical RS232 ports. These days, they are “virtual” ports set up over a Bluetooth or USB connection.
In the development of Windows 8, support for a variety of sensors, including GPS, was built into the operating system, and exposed by a new set of APIs. The point being that this means that there is a new set of interfaces for developers to use, and they are different from the traditional COM port interfaces.
So, as you might expect, traditional Windows navigation software, which has been written expecting to find GPS data coming in via traditional COM port interfaces, won’t see the new generation of GPS receivers being built directly into PC hardware running Windows 8.
And so it is. Here for example is the very latest version of Microsoft’s AutoRoute 2013. I downloaded a trial version and installed it on my Lenovo ThinkPad Tablet 2, which has a Broadcom GNSS Gelocation Sensor in it. As you can see, AutoRoute 2013 expects to find GPS data arriving via a COM port, and complains that it can’t find the GPS receiver:
What I find truly ironic about this is that Microsoft trumpets the fact that AutoRoute 2013 now has support for the Touch features of Windows 8:
However, the AutoRoute team has completely forgotten to use the new interfaces for GPS sensors that may be present in Windows 8 devices. Open mouth, change feet.
A further irony is given by the fact that when this issue was raised in a Microsoft forum, Janet Schneider, a Microsoft employee, blithely writes that
You can use the Location API and a Location Provider Driver to get NMEA strings, instead of using a virtual COM port.
Janet, please tell that to your fellow developers in Microsoft, not us, the poor users of this stuff. The left hand of Microsoft clearly has no clue what the right hand is doing.
Now what would be really useful is for someone in Microsoft to code a software shim that would connect a virtual COM port to a Location Provider Driver. That would enable us to carry on using our legacy Windows navigation software on Windows 8 tablets with GPS receivers. It would even allow the AutoRoute 2013 software to work as advertised.
Addendum: Well, Microsoft hasn’t bothered to write a software shim, or updated their Streets & Trips or AutoRoute software at this time of writing (December 2013), but at least two third parties have developed shims:
Addendum 25 February 2014: If you’re looking for a map application that has maps held on your Tablet, and which will work directly with the GNSS sensor in the ThinkPad Tablet 2, then the good news is that Nokia has released its HERE Maps App for all Windows 8.1 devices. Even better, it’s free.
Addendum 8 July 2014: Microsoft has announced that AutoRoute, Streets and Trips, and Mappoint will no longer be developed, and will be dropped. I can’t say that I’m surprised, but on the other hand there are many Line of Business applications that have been built on top of MapPoint services, so those will have to be migrated over to Bing, HERE or Google Maps…
Addendum 25 August 2015: And Microsoft drops the ball once more… I’m now seeing reports that Microsoft has changed something in Windows 10 that affects the traditional virtual COM ports. The effect is that Bluetooth GPS loggers no longer connect properly. This means that I can no longer use my Qstarz GPS logger with my Surface 3 to feed GPS data into the Microsoft Maps app. Honestly, I despair at Microsoft sometimes; they are their own worst enemy…
Addendum 30 August 2015: For those of us who are definitely having problems getting the SPP slave port to work, there could be some good news on the horizon…
I’ve just upgraded my Yoga 3 Pro to the latest Insider Preview build (10532), and the SPP problem seems to have been fixed. I’m able to connect my Qstarz GPS logger and get data. This result has been confirmed by another person who had the same problem with the 10240 build of Windows 10. I hope that this fix will be present in the October update to Windows 10 that will be available to everyone…
Addendum 1 October 2015: Microsoft has issued an update (KB3093266) to Windows 10 that fixes the virtual COM ports issue. Excellent.