On the Pocketnow Power User so far this season we’ve talked mainly about hardware. What is the hardware abstraction layer, and why should you care?

The Hardware Abstraction Layer (HAL) bridges the gap between hardware and software. Be warned, this topic is very, very geeky!

To begin with, the HAL isn’t a concept that’s unique only to smartphones and tablets. It’s been around for a quite a while, but it’s implemented differently depending on the environment that you’re talking about.

Hardware abstraction on an MS-DOS system is very different from that on a Mac, and from a technical standpoint it’s just as different on iOS, Android, and Windows Phone. It’s the concept that’s essentially the same, and that’s what we’re talking about today.

Hardware

Hardware is physical. It’s tangible. It’s something you can see with your eyes and touch with your fingers.

Hardware is the screen that displays information on your device. It’s the touch-input digitizer that you interact with. It’s your microphone and your speakers, and the buttons that you press to turn it on and off or adjust the volume.

Hardware is your camera and your radios for cellular, Bluetooth, WiFi, and NFC. It’s the batteries that power all that, and the connector that lets you charge the device and transfer data.

By itself, hardware doesn’t do much.

Software

Software is the code that developers (or “programmers”) write and compile that tells the hardware what to do. Some software can be described as “apps”, but those are mainly what I’d consider “front-end”. They exist to get information from some source, present it to you, the user, and let you act on it.

Other kinds of software could be the Operating System itself, or…

HAL

… the Hardware Abstraction Layer. This concept of the HAL used to be much more strict and rigid than it is today (and I’m sure plenty of comments will argue the old-school definition versus what we have today).

Back in the days of DOS-based computers, if you wanted to write a letter to your Mom (by the way, when was the last time you did that?) you’d fire up your word processor, type your letter, then print it out. To convert the information that you had just input onto a printed page is actually somewhat complex. The word processor had to have a print driver for your particular printer installed and configured, which would convert the letter into movements of the print head across the page, ultimately resulting in a letter you’d put in an envelope, address, stamp, and send to your Mom.

Although print manufacturers would often assist software developers to make this happen, the driver itself was encapsulated inside the app. Another program, your spreadsheet app, for example, would have to duplicate much of what was in the print driver in your word processor to enable printing from that program. One driver might be better than another resulting in great print-outs from one program, but sub-par print-outs from another.

In addition to taking up extra space on your disc, developing these drivers took time away from the writing the app itself, just to make printing work.

Once more “modern” operating systems like Windows (and others) came along, the operating system provided a common printing interface. The printer manufacturer would make a driver for Windows, and any program running in Windows could then print to it without having to reinvent the wheel.

Carry this same concept forward to all those other pieces of hardware, and you can start to see the true utility of abstracting the hardware away from direct communication with the individual devices.

Often time the HAL is a “thing” in and of itself. Other times those functions are carried out by the kernel. They could also be accomplished by device drivers. In many cases, all of these work together to accomplish the objective.

Today we’re taking that a step further through APIs — Application Programming Interfaces. These APIs still talk to the devices (either directly or through the HAL), but they are less specific. For example, if you want to know the device’s position, an app can now talk to a location API. That API can gather information from the barometer, digital compass, aGPS, WiFi, cellular radios, GLONASS, etc. The app doesn’t need to know how it’s getting the location data, nor does it have to make separate calls to each piece of hardware,  the API takes care of it. What’s more, the API might let you, the user, control the level of specificity that it reports back (exact location, or just in general, or not at all).

In short, the HAL and these APIs let developers focus on writing awesome apps, rather than worrying about communicating directly with hardware.