Back in the early 1970s, as an IBM mainframe systems programmer, I copied APIs to add functionality. E.g., the program that read JOB cards was JOBCTLA. If I wanted to extract accounting info from the job card, I would rename the IBM module to JOBCTXA and replace the original with my own version. It would do what I wanted, and then call the IBM version.

My wife and I have been watching the "Great Courses" course on "Cosmology" all summer and think it is a wonderful overview of the subject. We've watched 26 of 36 lessons and will definitely be finishing it. We have already decided that the next course will be "Dark Matter".

Unfortunately, it's relevant to many, many mission-critical applications that can't be converted easily to run under anything else.

FWIW, in the late 1960s and early 1970s is was common to replicate some of IBM's APIs in its DOS and OS operating systems. That was a standard for modifying system behavior. A simple example that I remember was writing renaming IBMs main job control routine JOBCTRLA to something like JOBCTLA2 and writing your own JOBCTRLA which would usually call JOBCTLA2 after it was done with its additional processing but might not. This was how job accounting was first implemented, i.e., reading additional info off job cards to determine who was to be charged for the job.

Most APIs are not unique. In most cases, the same API structure is used for many other purposes in other programs. But back in the late 1960s there was another reason to copy APIs, and that was to replace the module using it. In a simple example, assume a program called jobctla.dll that has a single API. I might have renamed jobctla.dll, with it's single API, to jobctlax.dll, and then replaced the original with my own jobctla.dll that did something new and eventually passed the same API parameters to the old jobctlax.dll. One common example of this was in early job accounting routines, where I would parse out additional account numbers, user ids and other info in a job card before it was passed on to the original job control processor.

Around 1983, in a meeting with Dr. Ted Hoff, the architect of the first microprocessor at Intel, the 4004, he gave me a perspective on ideas that has stayed with me. He said. "Everyone has ideas. It's only the people who can make something of them that count." From 1989-1999 I ran a software company and my employees used to come to me with great ideas for what the company should do next. Most of these were software developers. I told them that I couldn't commit the resources the idea needed, but I would give them all the leeway I could to make something of the idea themselves. And they hardly ever did. Programmers have software ideas. Non-programmers have software ideas. Some of each group will succeed in implementing them, but very few.

Acacia's patent examiner never looked at the Object View Broker technology from 1994. That in turn was based on an object-oriented semantic modeling tool called Open Books, released by Open Books, Inc, in Cambridge, MA around 1990. That was written in C and released for the OS/2 platform. It wasn't successful in the market because it came out much too early, but it was a brilliant piece of technology that most prospects didn't understand at that time. And Open Books itself was based on the Camps Planning Architecture, a LISP-based technology developed by Mitre Corporation for NASA and DOD in the 1980s. If I remember correctly, it was the basis for some of the early space shuttle mission planning system tools because of the way it could tie together different relational databases.