decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
It was, but there isn't a significant difference in this context | 393 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
ABIs and APIs
Authored by: Ian Al on Saturday, May 26 2012 @ 04:30 AM EDT
Actually, there is very little difference, in practice, between APIs and ABIs.
They are both used by programmers and both can only be used by referring to the
written description. Neither are ever visible to the programmer. (When was the
last time you looked through the binary numeric values in your executable file
looking for either of them?)

There is a slight difference in that the patterns in the executable that express
calling ABIs is more obvious than the patterns in the executable that express
calling APIs. Since neither are ever investigated, who cares?

There is the conceptual difference that higher level language programming
interfaces are usually processor agnostic and lower level languages are often
mnemonically symbolised instructions from the native processor instruction set.

In the case of the virtual processor, especially if the instructions are given
text labels rather than numeric values, APIs and ABIs are completely
indistinguishable since the language is always agnostic to the native processor.
It is cross-platform, after all. The interface structuring in the executable
file is equally obscured whether API or ABI.

For every program with an API there is a, usually concealed, matching ABI. If
there is no binary level way of passing instructions and parameters to the other
program, there is no way of interfacing, full stop.

We should refer to programming interfaces. If we want to specify a programming
interface that is written for a specified high level language then we should
call it by the name of the language as with Java PI or Python PI. We should be
aware that each one is associated with a native processor PI or it will not
work.

Having wittered on about APIs and ABIs at length, my final shot is that all of
the rubbish arguments put by Oracle, apply to both of them. If there is SSO in
the written expression of the ABI then Oracle will still be in there arguing
that it is protectable. It's a copyright thing. It's about written expression.

---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid!

[ Reply to This | Parent | # ]

ABIs and VMs
Authored by: Gringo_ on Saturday, May 26 2012 @ 09:12 AM EDT
What's the difference, really, when you think of it?

[ Reply to This | Parent | # ]

It was, but there isn't a significant difference in this context
Authored by: Anonymous on Saturday, May 26 2012 @ 09:17 AM EDT
In this context, there isn't really a significant difference between a
function's API and that function's ABI. (After all, the ABI *is* an API for an
assembly language programmer).

They both consist of a bunch of technical details that have to match 100% in
order to make something compatible. These are "functional" details,
and don't deserve copyright protection.

Even if they *did* involve enough creativity to possibly deserve copyright
protection, extending that protection to them would be harmful to society. It
would prevent anyone else from re-implementing the API (or ABI). In effect, it
would prevent the creation of new works that were compatible or interoperable,
extending "patent-like" protection to the ideas that make up the API
or ABI. This would have a lot of negative effects on the software eco-system.

Until this case, the extent of copyright law seemed clear: if you created your
own new work from scratch, it would not be considered infringing even if it
copied the necessary technical details of an API or ABI in order to achieve
compatibility. Because the re-implementor only has ONE POSSIBLE WAY to write
those details, or the result will not be compatible. Allowing the original
author to monopolize that ONE possible way, is harmful to society.

[ Reply to This | Parent | # ]

Why this is about API and not ABI
Authored by: bugstomper on Saturday, May 26 2012 @ 06:27 PM EDT
I know that Wikipedia is not a primary source, but the article about application binary interface does convey well the difference I want to highlight. The ABI would describe things such as the binary data structures and calling conventions, which Connectix would had to have copied to make sure that the software in the game programs could properly call the routines that they wrote in the BIOS emulator. But this case was more about something else that Connectix also copied, the list of which routines to put in the BIOS emulator, and what each routine required as arguments, what functions they performed, and what values they returned. That is the API, not the ABI. From wikipedia:

ABIs cover details such as:

  • data type, size, and alignment
  • the calling convention, which controls how functions' arguments are passed and return values retrieved
  • the system call numbers and how an application should make system calls to the operating system
  • and in the case of a complete operating system ABI, the binary format of object files, program libraries and so on.

[ ... ]

An ABI should not be confused with an application programming interface (API) which defines a library of routines to call, data structures to manipulate, and/or object classes to use in the construction of an application using that particular (often language specific) API.

[ Reply to This | Parent | # ]

To clarify, for non-programmers
Authored by: Anonymous on Sunday, May 27 2012 @ 02:01 AM EDT
You may recall earlier in this case, discussions on Groklaw about exactly what "an API" is.

Well, the definition of ABI is similarly mushy. Usually, the term ABI is used to refer to a set of technical rules for how function calls work at the binary level. It is a general term, with "the ABI" for a particular platform or compiler, meaning "the set of rules followed on this platform, or by this compiler, to carry out a function call". It includes details such as, how parameters are passed (at which offsets on the stack, or in which registers). It includes all of the rules that would be considered part of the "calling convention" of the platform, and sometimes other details (for example, policy about how to represent exception handling).

It can also be used to refer specifically to one method or function, in which case it refers to the specific way the ABI rules apply to that method or function (which is almost the same thing as the API of the function, except at the binary level). But this usage is less common. Programmers would usually just describe that as an API instead. Particularly because the API includes ideas about the semantics of the function (i.e. what the function is supposed to do) and the ABI does not. The ABI is strictly about mechanical details of how to call the function and how it returns a value. It does not say anything about which value the function *should* return. That is the province of the API.

Although Connectix reverse-engineered info from Sony's BIOS that included the ABI of the BIOS functions, most of what they learned--and needed to replicate in their replacement BIOS--was API info, not just ABI.

It was necessary, but not sufficient, to know exactly how (at the machine code level) PlayStation games would invoke the BIOS functions, and how they would expect the results of those functions to be returned. That is the ABI. But the more important and difficult task was to understand what the BIOS functions were supposed to do, which is not part of the ABI. Rather, it is part of the API.

The "ideas and non-protected functional elements" of the Sony BIOS that were extracted by Connectix and used in their replacement BIOS, were mostly or entirely, the APIs.

[ Reply to This | Parent | # ]

an API is isomorphic to its ABI
Authored by: matth on Tuesday, May 29 2012 @ 09:05 AM EDT
The act of compilation converts source code to machine-executable (including
VMs) code. The interfaces are not substantially changed in this process.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )