Unauthorized information and software development

So what information are we talking about here, and who has to authorize it?

Software depends on knowledge to make something work. As a house is built upon its foundation, software is built on certain types of knowledge that the developer believes to be stable.

Much software is written with a certain operating system in mind. For example, someone might have started out to write a program for Windows. How does the developer know how to make a program that will run on Windows? Well, Microsoft provides documentation on how to do this, and based on this documentation, the developer can access features in the operating system and produce a program that works correctly. This type of information is referred to nowadays as an Application Program Interface (API). If someone creates software (such as an operating system) that is intended to be used by other software, they generally document an API that gives this other software some reliable knowledge to build on.

So how can this information be “unauthorized”? Let’s go back in time to the early 1980s. At that time, a home computer was likely to be one of these:

  • Apple ][
  • Atari 800
  • Commodore 64
  • IBM PC (at first this was more of an office machine)

Of these, only the IBM PC has true “descendants” to this day. In fact, it is possible that someone could have written a program to work on an early IBM PC, and this program could still run on a modern computer. (I know this for a fact, as I wrote such a program.) How could this be?

Back in the early 1980s, IBM published the source code to its BIOS (Basic Input/Output System). This code contained copious comments (comments are text that doesn’t do anything computer-wise but provides the reader of the code with information). These comments documented the API of how one could write programs that worked on an IBM PC.

As a quick digression, it took some creativity for someone to figure out how to legally create an IBM PC “clone” that could run programs compatibly. Source code is generally considered the property of its creator, and it would have been illegal for someone to take the source code of IBM’s BIOS and copy it into their own BIOS. IBM published the source code but they still owned a copyright to it. So these “clone” creators wrote their own document containing only the API information, and passed it off to their own developers who were strictly forbidden from looking at the IBM source code. It turned out that it was legal for them to develop their own BIOS with the same API as long as they were not actually copying their code from IBM’s source code.

Anyway, software developers are a creative bunch, and wanted their programs to work as well as possible. This created a bit of a controversy. IBM had some functions in the BIOS to create text and graphics on the screen, and they said they wanted developers to please use their API to create their text and graphics. If they did this, IBM would guarantee that the same API would work for future IBM computers that hadn’t been invented yet.

But developers decided to ignore this request from IBM. They could look at the BIOS source code and see the workings of these text and graphics functions. The developers found that if they accessed the graphics hardware directly instead of using IBM’s API, their programs would run noticeably faster.

The developers were taking a risk here. Hypothetically, IBM could invent a new graphics card and change their graphics hardware completely. Along with this, IBM would also have to modify its BIOS code to work with this new graphics hardware. If developers used IBM’s API (as IBM had asked them to), their programs would continue to work. But if developers accessed the graphics hardware directly, their programs would no longer work with these hypothetical new graphics cards. If the developers complained to IBM, then IBM could say, “We warned you that you should have used our API. You should have listened to us.”

What actually happened, though, was that developers had almost universally decided that IBMs BIOS functions were too inefficient and slow. I recall having to decide how graphics should work in a program I was writing, and by this time it was considered “accepted practice” to access the graphics hardware directly. I decided to jump on the bandwagon and follow the crowd, abandoning the BIOS graphics functions like everyone else. If IBM ever radically changed their graphics card, I wouldn’t be any worse off than all those other developers who made the same decision.

In fact, the hypothetical situation never happened; IBM never changed the way their graphics cards worked. Maybe this was to make things easier for themselves. But another factor could have been that accessing the graphics hardware directly had become such widespread “accepted practice” that IBM was essentially trapped. Who would upgrade to IBM’s new graphics card if it wouldn’t work with any existing software?

So the “accepted practice” had won a victory over IBM’s documented API. As other manufacturers started to make their own graphics cards to use in these “clone” PCs, they all stayed compatible enough with IBM’s original design that existing software still worked.

But wait a minute, you say. Several paragraphs ago, I said that some of this old software would still work on a modern computer. But surely graphics cards have changed substantially in all those years. If I wrote a program in 1985 that accessed the graphics hardware directly, how can it still work over a quarter of a century later?

The answer is that this “accepted practice” won out in a bigger way than anyone would have expected. Back in the early 1990s, Windows 3.0 and then 3.1 quickly became the new standard for office computers. And Microsoft did a very clever thing. They knew all about the “accepted practice” of accessing graphics hardware directly, and they built into their operating system the appropriate stuff so that all of these old programs still worked!

I must admit I was rather stunned the first time I saw an old DOS-based program that I wrote using the “accepted practice” run perfectly fine inside an “MS-DOS window” in Windows 3.1. On an old IBM PC, my program occupied the whole screen and controlled the graphics hardware entirely on its own. But here it was running inside a window along with other windows running different programs that were on the screen at the same time. Windows 3.1 intercepted my program’s accesses to what my program “thought” was the graphics hardware, and it did the “equivalent” things so that my program would run correctly in a window!


So does this mean that you should use unauthorized information? No, it just means that IBM didn’t have the authority that it had hoped. The information was in a sense “authorized” by common practice, so in just this special case, the developers won out by ignoring the rules.

Oh, but despite that, it’s really really bad to depend on unauthorized information. Not that you’d know that from this story, but most of the time, “unauthorized information = bad”. Oh, and besides, “the exception proves the rule,” so, um, right, this story really shows that if you depend on unauthorized information, it would be bad. Yup, you’d definitely want to not be doing that. If you did, it would be like, all risky and stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *