答:简单地说，ABI与API的一个共同之处是它是一个接口。可重用程序公开了一个稳定的接口(API)，可用于在另一个程序中重用该程序。

B. However, an ABI is an interface issued for some specific processor-platform for some specific language. All compiler-vendors desiring to target that platform for that same language will have to ensure that not only compiled code in form of relocatable object codes comply with the interface to be able to link and cross-link with each other but also executables comply with it to be able to run on the platform at all. So, ABI is much broader set of specifications/standard than a typical function API. It may include some API objects to be enforced upon the language-users by the compiler. The compiler-vendor will have to include support for the same in their distributions. Needless to say, the platform vendor is the rightful authority to issue ABIs for its platform. Both compiler vendors and ABIs need to comply with the corresponding language-standard (e.g. ISO standard for C++).

C.平台供应商对ABI的定义是:

“1。可执行文件为了在特定的执行环境中执行而必须遵守的规范。例如，Arm架构的Linux ABI。

独立生成的可重定位文件必须遵守的规范的一个特定方面，以便静态可链接和可执行。例如，Arm架构的c++ ABI, Arm架构的运行时ABI, Arm架构的C库ABI。”

D.举例;基于Itanium架构的c++通用ABI也由一个联盟发布。平台供应商自己的c++的abi在多大程度上符合它完全取决于平台供应商。

E.作为另一个例子。Arm架构的c++ ABI在这里。

F.前面已经说过，处理器体系结构的ABI将确保一个可重用程序和另一个重用它的程序之间的API适用于该处理器体系结构。

G. That brings us to service-oriented components (e.g. SOAP-based web services). They too require an API to exist between a SOAP-based web service and client program (could be an app, front-end or another web service) for the client program to reuse the web service.The API is described in terms of standardized protocols like WSDL (interface description) and SOAP(message format) and is language-neutral and platform-neutral. It is not targeted to any specific processor-platform and thus it is not "binary" like ABI. A client-program on any one platform type and written in any language can remotely reuse a web service written in any other language and hosted on an entirely different processor-platform. This is made possible by the fact that both WSDL and SOAP are text-based (XML) protocols. In case of RESTful web services, the transport protocol http--also a text-based protocol-- itself acts as the API (CRUD methods).

总结

对于定义ABI(应用程序二进制接口)的确切层有各种各样的解释和强烈的意见。

在我看来，ABI是对特定API的给定/平台的主观约定。ABI是对于特定API“不会改变”的约定的“剩余”部分，或者由运行时环境解决:执行器、工具、链接器、编译器、jvm和OS。

定义接口:ABI, API

如果你想使用像joda-time这样的库，你必须声明一个依赖joda-time-<major>.<minor>.<patch>.jar。标准库遵循最佳实践并使用语义版本控制。这在三个层次上定义了API的兼容性:

补丁——你根本不需要修改你的代码。这个库只是修复了一些错误。 次要-你不需要改变你的代码，因为添加的东西(开闭原则是尊重的) 重要—接口(API)已更改，您可能需要更改代码。

为了让你使用同一个库的一个新的主要版本，还有很多其他的约定需要遵守:

库使用的二进制语言(在Java情况下是定义Java字节码的JVM目标版本) 调用约定 JVM规范 链接约定 运行时约定 所有这些都是由我们使用的工具定义和管理的。

例子

Java案例研究

例如，Java标准化了所有这些约定，不是在一个工具中，而是在一个正式的JVM规范中。该规范允许其他供应商提供一组不同的工具来输出兼容的库。

Java为ABI提供了另外两个有趣的案例研究:Scala版本和Dalvik虚拟机。

Dalvik虚拟机破坏了ABI

The Dalvik VM needs a different type of bytecode than the Java bytecode. The Dalvik libraries are obtained by converting the Java bytecode (with same API) for Dalvik. In this way you can get two versions of the same API: defined by the original joda-time-1.7.2.jar. We could call it joda-time-1.7.2.jar and joda-time-1.7.2-dalvik.jar. They use a different ABI one is for the stack-oriented standard Java vms: Oracle's one, IBM's one, open Java or any other; and the second ABI is the one around Dalvik.

Scala后续版本不兼容

Scala在次要的Scala版本之间不具有二进制兼容性:2。X。由于这个原因，相同的API“io。reactivex" %% "rxscala" % "0.26.5"有三个版本(将来会有更多):针对Scala 2.10、2.11和2.12。改变了什么?我现在不知道，但是二进制文件是不兼容的。可能最新的版本增加了一些东西，使得库在旧的虚拟机上无法使用，可能是与链接/命名/参数约定有关的东西。

Java连续版本是不兼容的

Java在JVM的主要版本上也有问题:4,5,6,7,8,9。它们只提供向后兼容性。Jvm9知道如何运行针对所有其他版本的编译/目标代码(javac的-target选项)，而JVM 4不知道如何运行针对JVM 5的代码。而你只有一个joda-library。由于有不同的解决方案，这种不兼容性变得显而易见:

语义版本控制:当库的目标是更高的JVM时，它们通常会改变主版本。 使用JVM 4作为ABI，您就安全了。 Java 9增加了一个关于如何在同一个库中包含特定目标JVM的字节码的规范。

为什么我要从API定义开始呢?

API and ABI are just conventions on how you define compatibility. The lower layers are generic in respect of a plethora of high level semantics. That's why it's easy to make some conventions. The first kind of conventions are about memory alignment, byte encoding, calling conventions, big and little endian encodings, etc. On top of them you get the executable conventions like others described, linking conventions, intermediate byte code like the one used by Java or LLVM IR used by GCC. Third you get conventions on how to find libraries, how to load them (see Java classloaders). As you go higher and higher in concepts you have new conventions that you consider as a given. That's why they didn't made it to the semantic versioning. They are implicit or collapsed in the major version. We could amend semantic versioning with <major>-<minor>-<patch>-<platform/ABI>. This is what is actually happening already: platform is already a rpm, dll, jar (JVM bytecode), war(jvm+web server), apk, 2.11 (specific Scala version) and so on. When you say APK you already talk about a specific ABI part of your API.

API可以移植到不同的ABI

抽象的顶层(针对最高API编写的源代码可以被重新编译/移植到任何其他较低层次的抽象。

假设我有一些rxscala的源代码。如果Scala工具改变了，我可以重新编译它们。如果JVM发生了变化，我就可以从旧机器自动转换到新机器，而不需要考虑高级概念。虽然移植可能很困难，但对任何其他客户端都有帮助。如果使用完全不同的汇编代码创建一个新的操作系统，则可以创建一个转换器。

跨语言移植的api

有些api可以移植到多种语言中，比如反应流。一般来说，它们定义到特定语言/平台的映射。我认为API是用人类语言甚至是特定的编程语言正式定义的主规范。在某种意义上，所有其他的“映射”都是ABI，比通常的ABI更多的API。REST接口也是如此。

术语ABI用于指代两个不同但相关的概念。

当谈到编译器时，它指的是用于从源级结构转换到二进制结构的规则。数据类型有多大?堆栈是如何工作的?如何将参数传递给函数?调用者和被调用者应该保存哪些寄存器?

当谈到库时，它指的是由编译库提供的二进制接口。这个接口是多种因素的结果，包括库的源代码、编译器使用的规则，以及在某些情况下从其他库中获得的定义。

对库的更改可以在不破坏API的情况下破坏ABI。例如，考虑具有如下接口的库。

void initfoo(FOO * foo)
int usefoo(FOO * foo, int bar)
void cleanupfoo(FOO * foo)

应用程序程序员编写的代码是

int dostuffwithfoo(int bar) {
  FOO foo;
  initfoo(&foo);
  int result = usefoo(&foo,bar)
  cleanupfoo(&foo);
  return result;
}

应用程序程序员并不关心FOO的大小或布局，但应用程序二进制文件最终会硬编码FOO的大小。如果标准库程序员在foo中添加了一个额外的字段，并且有人将新的标准库二进制文件与旧的应用程序二进制文件一起使用，那么标准库可能会进行越界内存访问。

OTOH，如果标准库的作者像这样设计他们的API。

FOO * newfoo(void)
int usefoo(FOO * foo, int bar)
void deletefoo((FOO * foo, int bar))

应用程序程序员编写的代码是

int dostuffwithfoo(int bar) {
  FOO * foo;
  foo = newfoo();
  int result = usefoo(foo,bar)
  deletefoo(foo);
  return result;
}

然后，应用程序二进制文件不需要知道任何关于FOO的结构，这些都可以隐藏在库中。你为此付出的代价是涉及到堆操作。

简而言之，从哲学上讲，只有某种类型的东西才能相处得很好，而ABI可以被看作是一种软件东西一起工作的东西。

让我至少回答你问题的一部分。通过一个例子说明Linux ABI如何影响系统调用，以及它为什么有用。

A systemcall is a way for a userspace program to ask the kernelspace for something. It works by putting the numeric code for the call and the argument in a certain register and triggering an interrupt. Than a switch occurs to kernelspace and the kernel looks up the numeric code and the argument, handles the request, puts the result back into a register and triggers a switch back to userspace. This is needed for example when the application wants to allocate memory or open a file (syscalls "brk" and "open").

现在系统调用有简短的名称“brk”等和相应的操作码，这些在系统特定的头文件中定义。只要这些操作码保持不变，您就可以使用不同更新的内核运行相同的已编译用户域程序，而无需重新编译。这样就有了预编译二进制文件使用的接口，因此就有了ABI。

如果您了解汇编以及操作系统级别的工作方式，那么您就符合特定的ABI。ABI控制参数的传递方式、返回值放置的位置等。对于许多平台来说，只有一种ABI可供选择，在这些情况下，ABI只是“事情如何工作”。

然而，ABI也控制着c++中类/对象的布局。如果您希望能够跨模块边界传递对象引用，或者如果您希望混合使用不同编译器编译的代码，这是必要的。

此外，如果您有一个可以执行32位二进制文件的64位操作系统，那么32位和64位代码将有不同的abi。

通常，链接到相同可执行文件中的任何代码都必须符合相同的ABI。如果希望在使用不同abi的代码之间进行通信，则必须使用某种形式的RPC或序列化协议。

我认为你过于努力地将不同类型的界面挤进一个固定的特征集。例如，一个界面不一定要分成消费者和生产者。接口只是两个实体交互的约定。

abi可以(部分地)与isa无关。有些方面(如调用约定)依赖于ISA，而其他方面(如c++类布局)则不依赖于ISA。

定义良好的ABI对于编写编译器的人来说非常重要。如果没有定义良好的ABI，就不可能生成可互操作的代码。

编辑:需要澄清的一些注释:

ABI中的“二进制”并不排除字符串或文本的使用。如果您想要链接一个导出c++类的DLL，则必须对其中的方法和类型签名进行编码。这就是c++名称破坏的用武之地。 您从未提供ABI的原因是绝大多数程序员都不会这样做。ABI是由设计平台(即操作系统)的人提供的，很少有程序员有特权设计一个广泛使用的ABI。