You might be more familiar with APIs than SOA but they had another meaning not very long ago.
The full episode tells how I used to program for DOS and how that is different from using APIs. Make sure to listen and subscribe in iTunes to get future episodes too automatically. You can also read the full transcript of the episode further below.
A big part of learning how to program Windows was actually learning about event-driven programming. But that’s another topic. A lot of the event-driven details are hidden from you these days with modern languages and programming platforms. If you ever need to program like this, then when you’re not sending event messages to various windows, you’ll be calling methods built into the operating system. Actually, even sending messages means that you’ll need to call a system method to send the message. All of these methods and the messages too are the documented way that an application can interact with Windows.
All of this ability to work with the operating system is called the Application Programming Interface or just API for short. If you write your own application that allows others to write code to interact with your application, then you’re providing your own API. An API really just means whatever mechanism is used by another application to programmatically make requests and send and receive information.
This is different from a GUI which is the Graphical User Interface. Or as it’s often known today as just the UI which is the User Interface. The user interface, whether graphical or not, is how a user interacts with your application. And that’s different from how a programmer writes another application to use your application. Programmers use APIs.
Sometimes these APIs might be referred to as low-level APIs or system APIs to distinguish them from a newer meaning that’s grown popular in the last several years.
It’s common now for API to mean something very different. When you want to write an application to interact with a web service, you’re getting into the newer meaning. Let’s say you wanted to write an application to gather tweets from Twitter and present them in some cool new way. How are you going to get the tweets in the first place? You’ll need to ask Twitter for them. But you’re not going to make a call directly into some method running in some dynamically linked library in some server operated by Twitter.
Instead, you request permission from Twitter to be able to make web service requests on behalf of some Twitter user. The new meaning of APIs usually means that you’ll be making REST calls and getting back either XML or JSON formatted information. All of that will need to be in a future episode.
Transcript
I remember when I was first learning how to program professionally. I was working for a small company in Singapore and the product was ready to ship. Some early customers asked a similar question, “Did we have a Windows version?” You see, the product I first helped build was written for DOS.
I wanted to learn how to program for Windows and bought the Software Development Kit or SDK from Microsoft in Singapore. They didn’t even know what it was at the time so I was definitely one of the first to explore this new way of programming.
But before I get to that, let me explain a bit about how things were done up to then. That was a long time ago and I might have forgotten some things. But what I do remember was anytime I needed to make a request from DOS.
I guess I should also explain what DOS was. It stood for Disk Operating System. Yeah, having a floppy disk in your computer was a big thing back then. And the disks really were floppy, too. This was before the stiffer 3 and a half inch disks became popular. DOS was a text-based operating system and was responsible running the computer just like a modern operating system such as Windows. All commands had to be typed. There was no pointing or clicking. In fact, early versions of Windows before Windows 95 were loaded after starting DOS first. All Windows was back then was a nice shell that provided some graphical operations.
So back to programming for DOS. Anytime I needed to ask the operating system to do something such as open a file to read its contents, the way this was done was to first create a string with the file path in memory and then set one of the internal processor registers to point to this string. Other registers would need to be changed too with values representing what operation was needed and any options. For example, both deleting a file and opening a file needed a string to identify the path to the file but are very different operations.
Once all this was setup just right, I would interrupt the processor. That’s it. Oh, except for one small detail. A lot of the really interesting things that DOS could do were undocumented. I had a book that described a lot of this. But even a book didn’t know everything. I still remember the interrupt number was 52.
What does all this mean? Let me give you an example. As I’m recording this episode, Florida is preparing for hurricane Matthew. So let’s say that you have several well rehearsed emergency procedures that you’ve been practicing. You’ve got several for dealing with tornados. Another group of procedures for how to deal with earthquakes. In fact, you have so many that you decide to number each group. I wish I was this prepared. Anyway, let’s say that all your hurricane procedures are in group 52.
The way it works is like this, the local news station first displays a map of the approaching hurricane, puts up some numbers identifying wind speeds, and makes a recommendation to evacuate the islands. Then, the station gets your attention by displaying a big banner that says, “Breaking News.” That gets your attention and causes you to look up from your dinner plate to read everything and make a decision about what you’re going to do.
In many ways, that’s exactly how to write a program for DOS. Setup all the required information and then issue a numbered interrupt. The interrupt gets the attention of the processor and it does what you ask.
Now that you have this historical perspective, I’ll describe how the Windows SDK made things a lot better and then how it all changed again, right after this message from our sponsor.
How would you like for me to show you exactly how to write a real game from start to finish? I actually discussed this in last week’s episode 151 about how I’m still working on this. The game week is still on. I just have to allow some more time to prepare a library that will allow you to build a game. This will show you everything you need to go from a complete beginner to writing your own game. Let me know if you’re interested by texting gameweek as a single word to the short number 44222 and I’ll give you all the details.
I remember feeling a bit cheated by the SDK, or Software Development Kit, for Windows because, well, it wasn’t really a kit at all. At least not in the sense I was used to. When I was little, a kit meant a box with a bunch of plastic or wooden pieces that I’d have to cut, paint, and glue together to make something. The SDK was just some documentation. Everything that I needed to write a Windows application was already included with Windows and the compiler tools that I already had. I quickly got over my feelings and learned how to program for Windows. It was like entering a new world.
There were dynamic libraries that my program could link with that contained methods I could call just like any other method. The SDK provided the documentation for how to call these methods. Now, if I wanted to open a file, there was a method that would do that.
A big part of learning how to program Windows was actually learning about event-driven programming. But that’s another topic. When I wasn’t sending event messages to various windows, I was calling methods built into the operating system. Actually, even sending messages meant that I had to call a system method to send the message. All of these methods and the messages too were the documented way that an application could interact with Windows.
I should add that there was still quite a bit of undocumented behavior that was hidden from ordinary programmers outside of Microsoft. And that Microsoft got into a lot of trouble for this and eventually changed.
All of this ability to work with the operating system was called the Application Programming Interface or just API for short. If you write your own application that allows others to write code to interact with your application, then you’re providing your own API. An API really just means whatever mechanism is used by another application to programmatically make requests and send and receive information.
This is different from a GUI which is the Graphical User Interface. Or as it’s often known today as just the UI which is the User Interface. The user interface, whether graphical or not, is how a user interacts with your application. And that’s different from how a programmer writes another application to use your application. Programmers use APIs.
Sometimes these APIs might be referred to as low-level APIs or system APIs to distinguish them from a newer meaning that’s grown popular in the last several years.
It’s common now for API to mean something very different. When you want to write an application to interact with a web service, you’re getting into the newer meaning. Let’s say you wanted to write an application to gather tweets from Twitter and present them in some cool new way. How are you going to get the tweets in the first place? You’ll need to ask Twitter for them. But you’re not going to make a call directly into some method running in some dynamically linked library in some server operated by Twitter.
Instead, you request permission from Twitter to be able to make web service requests on behalf of some Twitter user. The new meaning of APIs usually means that you’ll be making REST calls and getting back either XML or JSON formatted information. All of that will need to be in a future episode.