We program to the interface, thanks to Microsoft

Today's markets for PCs, for smart phones, and for tablets show a healthy choice of devices. PCs, phones, and tablets are all available from a variety of manufacturers, in a variety of configurations. And all run just about everything written for the platform (Android tablets run all Android applications, Windows PCs run all Windows applications, etc.).

We don't worry about compatibility.

It wasn't always this way.

When IBM delivered the first PC, it provided three levels of interfaces: hardware, BIOS, and DOS. Each level was capable of some operations, but the hardware level was the fastest (and some might argue the most versatile).

Early third-party applications for the IBM PC were programmed against the hardware level. This was an acceptable practice, as the IBM PC was considered the standard for computing, against which all other computers were measured. Computers from other vendors used different hardware and different configurations and were thus not compatible. The result was that the third-party applications would run on IBM PCs and IBM PCs only, not on systems from other vendors.

Those early applications encountered difficulties as IBM introduced new models. The IBM PC XT was very close to the original PC, and just about everything ran -- except for a few programs that made assumptions about the amount of memory in the PC. The IBM PC AT used a different keyboard and a different floppy disk drive, and some software (especially those that used copy-protection schemes) would not run or sometimes even install. The EGA graphics adapter was different from the original CGA graphics adapter, and some programs failed to work with it.

The common factor in the failures of these programs was their design: they all communicated directly with the hardware and made assumptions about it. When the hardware changed, their assumptions were no longer valid.

We (the IT industry) eventually learned to write to the API, the high-level interface, and not address hardware directly. This effort was due to Microsoft, not IBM.

It was Microsoft that introduced Windows and won the hearts of programmers and business managers. IBM, with its PS/2 line of computers and OS/2 operating system struggled to maintain control of the enterprise market, but failed. I tend to think that IBM's dual role in supplying hardware and software helped in that demise.

Microsoft supplied only software, and it sold almost no hardware. (It did provide things such as the Microsoft Mouse and the Microsoft Keyboard, but these saw modest popularity and never became standards.) With its focus on software, Microsoft made its operating system run on various hardware platforms (including processors such as DEC's Alpha and Intel's Itanium) and Microsoft focussed on drivers to provide functionality. Indeed, one of the advantages of Windows was that application programmers could avoid the effort of supporting multiple printers and multiple graphics cards. Programs would communicate with Windows and Windows would handle the low-level work of communicating with hardware. Application programmers could focus on the business problem.

The initial concept of Windows was the first step in moving from hardware to an API.

The second step was building a robust API, one that could perform the work necessary. Many applications on PCs and DOS did not use the DOS interface because it was limited, compared to the BIOS and hardware interfaces. Microsoft provided capable interfaces in Windows.

The third step was the evolution of Windows. Windows 3 evolved into Windows 3.1 (which included networking), Windows 95 (which included a new visual interface), and Windows 98 (which included support for USB devices). Microsoft also developed Windows NT (which provided pre-emptive multitasking) and later Windows 2000, and Windows XP.

With each generation of Windows, less and less of the hardware (and DOS) was available to the application program. Programs had to move to the Windows API (or a Microsoft-supplied framework such as MFC or .NET) to keep functioning.

Through all of these changes, Microsoft provided specifications to hardware vendors who used those specifications to build driver programs for their devices. This ensured a large market of hardware, ranging from computers to disk drives to printers and more.

We in the programming world (well, the Microsoft programming world) think nothing of "writing to the interface". We don't look to the hardware. When faced with a new device, our first reaction is to search for device drivers. This behavior works well for us. The early marketing materials for Windows were correct: application programmers are better suited to solving business problems than working with low-level hardware details. (We *can* deal with low-level hardware, mind you. It's not about ability. It's about efficiency.)

Years from now, historians of IT may recognize that it was Microsoft's efforts that lead programmers away from hardware and toward interfaces.