|
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 | # ]
|
- sorry, you're confused - Authored by: xtifr on Sunday, May 27 2012 @ 12:09 AM EDT
- API != ABI - Authored by: Anonymous on Sunday, May 27 2012 @ 02:12 AM EDT
- API != ABI - Authored by: Ian Al on Monday, May 28 2012 @ 03:49 AM EDT
- API != ABI - Authored by: Anonymous on Monday, May 28 2012 @ 08:12 AM EDT
- Pedantry! - Authored by: Ian Al on Monday, May 28 2012 @ 02:14 PM EDT
- Pedantry! - Authored by: Anonymous on Monday, May 28 2012 @ 02:25 PM EDT
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
|
|
|