Of the many character roles played by Windows, the one that probably gets the least coverage is its use in public as the underlying technology behind embedded applications such as kiosks and information panels. Earlier this year, I interviewed a designer of embedded systems who had been unwavering in using Windows as his choice for embedded operating systems. But, after years of dedication to Windows, he was considering alternatives. Until that interview, almost all of my exposure to embedded Windows, or something like it, was through public Web terminals and headless displays. If you travel, you know what I'm talking about. With many such applications, it's sometimes difficult if not impossible to tell what the underlying OS is because users typically have no access to the OS (as well it should be with embedded OSes). But occasionally, you'd see one of three tell-tale signs that Windows was in use under the hood.
The first of these are the signature window-boxes, title-bars, and controls that are fairly unique to Winapps. Many embedded applications hide these "Windows identifiers" (and rightfully so). But sometimes, they're unavoidable as is the case in the second tell-tale sign: a Windows error message. In public places, I see these so often. Every time I see one, I wish I had a digital camera with me. It's not that the error is always the fault of Windows (it's not). It's that any Windows-based kiosk that's disabled as a result of a bug is more than just a bad advertisement for the kiosk provider. It looks bad for the establishment that allowed that provider on premises (usually as the exclusive kiosk provider) as well as for Microsoft. It makes me wonder why such systems (at least the ones I keep seeing) aren't more self-aware of their state and capable on some level of self-repair (or at least an automatic reboot). Or, why isn't someone monitoring a remote console from where they can detect malfunctioning systems and either do an over-the-wire manual reboot, an over-the-wire app/os reprovisioning of the system (surely, the blade people keep telling us how easy this is to do), or simply disable the system temporarily instead of advertising that the system is screwed and it's just going to be left there for all passers-by to observe. Even in the case of terminals with a keyboard and pointing device or kiosks (like an Internet terminal), it probably couldn't hurt to have a big red publicly accessible reboot button in case something goes wrong (with instructions like "PRESS HERE IN CASE SYSTEM STOPS WORKING").
Last week, while vacationing to Mexico, I happened to have my camera with me. The first time I noticed a problem, my family and I were making a flight connection in Houston on the way to our final destination in Mexico. The error dialog appeared over some sort of digital information panel that was on display in multiple locations throughout the airport. Everywhere I looked, I saw the same error message, obstructing the view of the information behind it. That was over a week ago. But we were in such a hurry that I didn't have time to get out the digital camera and take the shot. However, eight days later, on the way back, a bug (I'm not sure if it was the same one) was on prominent display on the same information panels throughout the airport (see photo below). In this case, the dialog, which is hard to see clearly in my photo, is a "The program is not responding" dialog and the offending program, according to the dialog's title bar, is HtmlDve-Multi.e. Google turned up nothing on this.
The tell-tale signs that it was Windows weren't just the familiar Windows accoutrements, but also the instructions "To return to Windows and check the status of the program, click Cancel." This of course is a pretty silly message to display on an information panel that has no way for users to perform a click -- a sign to me that, whether it's the fault of Microsoft, the application provider, or the application deployer, somewhere, someone is doing a really bad job of adapting a desktop or server-based operating environment to a more public environment. At this point, open source advocates will probably chime in to remind everybody that open source operating systems like Linux are better-suited to the task because of how such error dialogs can be more easily customized through the sort of software re-engineering that open source licensing permits.
I caught a similar situation in the airport at Ixtapa, Mexico where, as you can see by the photo below, I was standing in front of a credit-card operated Windows-based Internet access terminal that is based on Windows 2000. (You can see the credit card slot off to the right.) The problem? The system seemed to have hung while Windows was starting up. There was no big red button. Just a display that showed the system sitting there having advanced about half-way through its startup sequence. Had it been working, I would have used it to get my first update on what was going on in the real world after having been incommunicado for a week. Unfortunately, that Internet Access Provider would not be ringing the cash register with me.
Another tell-tale sign that Windows is under the hood -- one that I don't see as much of anymore -- is the infamous Window Blue Screen of Death (BSOD). I guess that's a good sign that the BSOD isn't as common as it once was. Lest I single Windows out as a common denominator to all the problems I've seen, it's not. Last fall, while dropping my son off at Logan Airport for a trip to Florida, I spotted a string of terminals that were obviously having problems, in their pre-OS load mode, contacting a remote boot server. What struck me as being odd was the plethora of diagnostic information that appeared on the screen, including the MAC (physical layer) addresses of terminals as well as enough information to determine what local IP subnet they were on. While I'm not an expert in airport security (feel free to comment below if you can expound), this seemed to me to be the sort of information about an airport's digital infrastructure that the airport would rather not have on public display.
To be fair, more of these terminals and kiosks are probably in good working condition than not. In many cases, because of the way the underlying OS is so nicely concealed, the users will never know with some of them that Windows is under the hood providing the reliable service. Also, Linux is undoubtedly the driving force behind many "public applications" as well and has probably had its fair share of failures in public environments. It's just that I've never had the privilege of seeing such an occurence.