Something that I started at Microsoft was Hardware Ecosystem Managment, well, I always called it Hardware Evangelism.  Immediately following Windows 3.11 shipping, Microsoft recognized that PC’s at the time were too hard to configure.  A lot of people reading this post won’t have the faintest clue of what I’m talking about when I say you used to have to know about IRQ’s, DMA addresses and jumpers.  For the folks from the UK I’m not talking about sweaters.  I’m talking about all these things you needed to configure to add a new card to your PC, or connect a printer or attempt to add a new hard disk to  your system.  All these things were monstrously hard to do before Windows 95, USB and Bluetooth weren’t even things I could even have fantasized about.

So, what about applying Evangelism to….  hardware?  Well, many of the same principles applied.  Remember, there are things called device drivers that have to be written.  Firmware in ROMs need to be written to support new chipset features.  Protocols need to be understood by each subsystem of the operating system to discover, enable and configure new hardware devices.  So what did we do at Microsoft?  Well of course we created a conference, I of course creatively named it the “Windows Hardware Engineering Confernence” or as it became known in the industry, WinHEC.  We distributed Device Driver Development Kits, or DDKs.  We worked with standards bodies, industry groups, chip makers like Intel, companies who made motherboards,BIOS makers, third party chip set makers, display card vendors, harddrive vendors, the list goes on….

So all this information was published in a book called the “Hardware Design Guide for Windows ’95”, a description of all the new protocols, subsystems, interfaces and signaling that the Windows 95 kernel made available to implement the first implementation of Plug and Play on the PC.  This is what you know today, in most cases you just plug something into the PC and it just works, er, most of the time.  This book described the operating systems requirements to the PC hardware ecosystem to allow their devices to fully participate in Plug and Play.

To test these new Plug and Play devices with Windows our team hosted innumerable “Plug a thons” and for some devices “Connect a thons”, to be honest, after all these years I can’t remember what was different about the two events.   We created a new Logo Program and the “Windows Hardware Quality Lab” that managed the logo program and outside testing firms to certify both the new device drivers and the new hardware so consumers could easily identify Plug and Play enabled devices and PCs.

We even worked with the standalone chip foundries to insure runs of specialized chips were in the supply chain.

So why am I bringing this up?  Today many new startups are building devices that either interface to mobile devices via Bluetooth or WiFi, and solutions we pioneered with Plug and Play will be required to insure interoperability with each mobile platform as well insuring that your device plays well with other devices using the wireless connectivity.   In essence, some things never change, scenarios we worked through in the early ’90s for Windows are with us today, just in a different packaging and now wireless.  Which means right now there’s probably a Connect a thon running somewhere in the world….