I was chief architect of a Windows based signage player platform (Inspired Signage ) from the late 1990’s until 2010. I’ve learned a lot in that time, and I wanted to write something to help all those companies doing it today who perhaps don’t have 12+ years of painful experience behind them.
LHR T5 Nokia screens needed love earlier this year
I see too many examples on my travels of BSODs (Blue Screens of Death), pop up windows, windows desktops, taskbars and mouse cursors, when what I should be seeing is beautiful content. Windows is derided as a platform for exactly these issues, none of which are usually the fault of Windows itself.
So here are some easy things you can do to avoid them.
- Test your hardware and OS image, ship it, don’t change it. Apart from physical hardware failure, every BSOD I’ve ever seen is a driver bug. Errors in application software cannot cause a BSOD. Test your players on the shelf for at least a week before shipping. If you have time to test for a month, do so. Set up a mains timer to switch the power on and off several times an hour so that you know it copes with power failure on site. This also puts it through a frequent boot sequence. Once it’s shipped, DON’T upgrade the drivers in the field except to fix a bug that you’re experiencing IN THE FIELD. If they worked last year, then they’ll work next year
- Windows Update. Turn it off. Yes, it’s there for security updates, to stop you getting worms etc. We had several thousand Inspired Signage players in the field and not a single one got a virus. Why? We had a firewall to stop unsolicited stuff getting in, and there wasn’t a user opening dodgy emails or webpages. If you really have to have it turned on, minimise what it can do to only take security updates and not software updates like service packs
- Windows Firewall. Turn it on. Set it up to ONLY allow traffic on the ports you use to update content and remotely manage the player. Minimise the incoming ports. If you can put your players on a VPN or VLAN so that only the management system can get an IP route to them, even better. If not, restrict incoming ports by IP address so that only your NOC can access them
- Anti Virus. Choose carefully. If possible, don’t install anti virus software – it just gets in the way. Use your firewalling (see above) to stop anything getting to your machine in the first place. 99% of the Inspired players in the field had no anti virus, and never needed it. If you do have to put one on (corporate IT rules are the usual reason), then make sure you choose an enterprise one which notifies you by email etc if it has a problem (like its license has expired), and DOES NOT pop up a window for a user. Remember, there isn’t a keyboard and mouse on this box
- The biggie. Don’t use Windows Explorer. I don’t mean Internet Explorer, I mean Explorer. To the uninitiated, that’s your desktop and Start Bar. Too many installations use the auto run functions of Explorer to start their software. What’s wrong with this? Well… it’s all too easy to have the Windows task bar pop up on top of your content, and if your software ever crashes, you see the Windows desktop, rather than a black screen
- Set your software to run as the shell. Google it – all you have to do is set a registry key – you can do this with any software. That means you’re responsible for launching all your apps. So don’t have multiple applications: Launch your graphics renderer application as the shell, and have any other apps (e.g. watchdog, or reporting) run as services. This way they have no GUI and *cannot* appear on screen
- Turn off the mouse cursor. Please! Most of the time, if you have no mouse plugged in, you won’t get a mouse cursor. Sometimes, Windows forgets and plops it up. So just set the cursor on your main form to null. Then you can’t get caught out. Especially if you have an LED screen – I’ve seen too many 8” mouse cursors!
- Software crashes. There’s really only one reason why Windows applications crash and are shut down by Windows. It’s due to an unhandled exception in a thread . This is one that only the developers can fix. Whenever you start a thread, wrap the inside of the main loop in an exception handler. I mean when you first write it. Before you do anything else! Have that exception handler log the error and call stack over the internet to your development bug tracking system (you do have an automated in the field bug tracking system?). Aspect Oriented programming can really help here (e.g. PostSharp) – if you need help setting up such a system, Silver Curve can advise you or help you build one, Ed
Hope that helps – everyone from resellers to integrators to manufacturers should be able to get something useful from this (if they didn’t know it already!).
Have a good and BSOD free 2012!