jkerian :
I mostly come across these terms in the sense of an API-incompatible change, or an ABI-incompatible change.\n\nAn API change is essentially where code that would have compiled with the previous version won't work anymore. This can happen because you added an argument to a function, or changed the name of something accessible outside of your local code. Any time you change a header, and it forces you to change something in a .c/.cpp file, you've made an API-change.\n\nAn ABI change is where code that has already been compiled against version 1 will no longer work with version 2 of a codebase (usually a library). This is generally trickier to keep track of than API-incompatible change since something as simple as adding a virtual method to a class can be ABI incompatible.\n\nI've found two extremely useful resources for figuring out what ABI compatibility is and how to preserve it:\n\n\nThe list of Do's and Dont's with C++ for the KDE project\nUlrich Drepper's How to Write Shared Libraries.pdf (primary author of glibc)\n",
2010-09-24T06:32:05
Ciro Santilli OurBigBook.com :
Linux shared library minimal runnable API vs ABI example\nThis answer has been extracted from my other answer: What is an application binary interface (ABI)? but I felt that it directly answers this one as well, and that the questions are not duplicates.\nIn the context of shared libraries, the most important implication of "having a stable ABI" is that you don't need to recompile your programs after the library changes.\nAs we will see in the example below, it is possible to modify the ABI, breaking programs, even though the API is unchanged.\nmain.c\n#include <assert.h>\n#include <stdlib.h>\n\n#include "mylib.h"\n\nint main(void) {\n mylib_mystruct *myobject = mylib_init(1);\n assert(myobject->old_field == 1);\n free(myobject);\n return EXIT_SUCCESS;\n}\n\nmylib.c\n#include <stdlib.h>\n\n#include "mylib.h"\n\nmylib_mystruct* mylib_init(int old_field) {\n mylib_mystruct *myobject;\n myobject = malloc(sizeof(mylib_mystruct));\n myobject->old_field = old_field;\n return myobject;\n}\n\nmylib.h\n#ifndef MYLIB_H\n#define MYLIB_H\n\ntypedef struct {\n int old_field;\n} mylib_mystruct;\n\nmylib_mystruct* mylib_init(int old_field);\n\n#endif\n\nCompiles and runs fine with:\ncc='gcc -pedantic-errors -std=c89 -Wall -Wextra'\n$cc -fPIC -c -o mylib.o mylib.c\n$cc -L . -shared -o libmylib.so mylib.o\n$cc -L . -o main.out main.c -lmylib\nLD_LIBRARY_PATH=. ./main.out\n\nNow, suppose that for v2 of the library, we want to add a new field to mylib_mystruct called new_field.\nIf we added the field before old_field as in:\ntypedef struct {\n int new_field;\n int old_field;\n} mylib_mystruct;\n\nand rebuilt the library but not main.out, then the assert fails!\nThis is because the line:\nmyobject->old_field == 1\n\nhad generated assembly that is trying to access the very first int of the struct, which is now new_field instead of the expected old_field.\nTherefore this change broke the ABI.\nIf, however, we add new_field after old_field:\ntypedef struct {\n int old_field;\n int new_field;\n} mylib_mystruct;\n\nthen the old generated assembly still accesses the first int of the struct, and the program still works, because we kept the ABI stable.\nHere is a fully automated version of this example on GitHub.\nAnother way to keep this ABI stable would have been to treat mylib_mystruct as an opaque struct, and only access its fields through method helpers. This makes it easier to keep the ABI stable, but would incur a performance overhead as we'd do more function calls.\nAPI vs ABI\nIn the previous example, it is interesting to note that adding the new_field before old_field, only broke the ABI, but not the API.\nWhat this means, is that if we had recompiled our main.c program against the library, it would have worked regardless.\nWe would also have broken the API however if we had changed for example the function signature:\nmylib_mystruct* mylib_init(int old_field, int new_field);\n\nsince in that case, main.c would stop compiling altogether.\nSemantic API vs Programming API\nWe can also classify API changes in a third type: semantic changes.\nThe semantic API, is usually a natural language description of what the API is supposed to do, usually included in the API documentation.\nIt is therefore possible to break the semantic API without breaking the program build itself.\nFor example, if we had modified\nmyobject->old_field = old_field;\n\nto:\nmyobject->old_field = old_field + 1;\n\nthen this would have broken neither programming API, nor ABI, but main.c the semantic API would break.\nThere are two ways to programmatically check the contract API:\n\ntest a bunch of corner cases. Easy to do, but you might always miss one.\nformal verification. Harder to do, but produces mathematical proof of correctness, essentially unifying documentation and tests into a "human" / machine verifiable manner! As long as there isn't a bug in your formal description of course ;-)\n\nTested in Ubuntu 18.10, GCC 8.2.0.",
2019-03-03T15:34:52
Anycorn :
This is my layman explanations:\n\n\nAPI - think of include files. They provide programming interfaces.\nABI - think of kernel module. When you run it on some kernel, it has to agree on how to communicate without include files, i.e. as low-level binary interface.\n",
2010-09-24T05:28:43
Premraj :
(Application Binary Interface) A specification for a specific hardware platform combined with the operating system. It is one step beyond the API (Application Program Interface), which defines the calls from the application to the operating system. The ABI defines the API plus the machine language for a particular CPU family. An API does not ensure runtime compatibility, but an ABI does, because it defines the machine language, or runtime, format. \n\n\n\nCourtesy",
2017-02-05T02:57:43
user7610 :
Let me give a specific example how ABI and API differ in Java.\nAn ABI incompatible change is if I change a method A#m() from taking a String as an argument to String... argument. This is not ABI compatible because you have to recompile code that is calling that, but it is API compatible as you can resolve it by recompiling without any code changes in the caller.\nHere is the example spelled out. I have my Java library with class A\n // Version 1.0.0\n public class A {\n public void m(String string) {\n System.out.println(string);\n }\n }\n\nAnd I have a class that uses this library\n public class Main {\n public static void main(String[] args) {\n (new A()).m("string");\n }\n }\n\nNow, the library author compiled their class A, I compiled my class Main and it is all working nicely. Imagine a new version of A comes\n // Version 2.0.0\n public class A {\n public void m(String... string) {\n System.out.println(string[0]);\n }\n }\n\nIf I just take the new compiled class A and drop it together with the previously compiled class Main, I get an exception on attempt to invoke the method\nException in thread "main" java.lang.NoSuchMethodError: A.m(Ljava/lang/String;)V\n at Main.main(Main.java:5)\n\nIf I recompile Main, this is fixed and all is working again.",
2017-02-22T16:08:01
ZhouZhuo :
Your program (source code) can be compiled with modules who provide proper API.\n\nYour program (binary) can run on platforms who provide proper ABI.\n\nAPI restricts type definitions, function definitions, macros, sometimes global variables a library should expose.\n\nABI restricts what a \"platform\" should provide for you program to run on. I like to consider it in 3 levels:\n\n\nprocessor level - the instruction set, the calling convention\nkernel level - the system call convention, the special file path convention (e.g. the /proc and /sys files in Linux), etc.\nOS level - the object format, the runtime libraries, etc.\n\n\nConsider a cross-compiler named arm-linux-gnueabi-gcc. \"arm\" indicates the processor architecture, \"linux\" indicates the kernel, \"gnu\" indicates its target programs use GNU's libc as runtime library, different from arm-linux-androideabi-gcc which use Android's libc implementation.",
2017-10-21T07:01:32
yoAlex5 :
API - Application Programming Interface is a compile time interface which can is used by developer to use non-project functionality like library, OS, core calls in source code\n\nABI[About] - Application Binary Interface is a runtime interface which is used by a program during executing for communication between components in machine code ",
2019-12-10T15:33:21
Lewis Kelsey :
The ABI refers to the layout of an object file / library and final binary from the perspective of successfully linking, loading and executing certain binaries without link errors or logic errors occuring due to binary incompatibility.\n\nThe binary format specification (PE, COFF, ELF, .obj, .o, .a, .lib (import library, static library), .NET assembly, .pyc, COM .dll): the headers, the header format, defining where the sections are and where the import / export / exception tables are and the format of those\nThe instruction set used to encode the bytes in the code section, as well as the specific machine instructions\nThe actual signature of the functions and data as defined in the API (as well as how they are represented in the binary (the next 2 points))\nThe calling convention of the functions in the code section, which may be called by other binaries (particularly relevant to ABI compatibility being the functions that are actually exported)\nThe way data is represented and aligned in the data section with respect to its type (particularly relevant to ABI compatibility being the data that is actually exported)\nThe system call numbers or interrupt vectors hooked in the code\nThe name decoration of exported functions and data\nLinker directives in object files\nPreprocessor / compiler / assembler / linker flags and directives used by the API programmer and how they are interpreted to omit, optimise, inline or change the linkage of certain symbols or code in the library or final binary (be that binary a .dll or the executable in the event of static linking)\n\nThe bytecode format of .NET C# is an ABI (general), which includes the .NET assembly .dll format. The virtual machine that interprets the bytecode has a specific ABI that is C++ based, where types need to be marshalled between native C++ types that the native code's specific ABI uses and the boxed types of the virtual machine's ABI when calling bytecode from native code and native code from bytecode. Here I am calling an ABI of a specific program a specific ABI, whereas an ABI in general, such as 'MS ABI' or 'C ABI' simply refers to the calling convention and the way structures are organised, but not a specific embodiment of the ABI by a specific binary that introduces a new level of ABI compatibility concerns.\nAn API refers to the set of type definitions exported by a particular library imported and used in a particular translation unit, from the perspective of the compiler of a translation unit, to successfully resolve and check type references to be able to compile a binary, and that binary will adhere to the standard of the target ABI, such that if the library that actually implements the API is also compiled to a compatible ABI, it will link and work as intended. If the API is updated the application may still compile, but there will now be a binary incompatibility and therefore a new binary needs to be used.\nAn API involves:\n\nFunctions, variables, classes, objects, constants, their names, types and definitions presented in the language in which they are coded in a syntactically and semantically correct manner\nWhat those functions actually do and how to use them in the source language\nThe source code files that need to be included / binaries that need to be linked to in order to make use of them, and the ABI compatibility thereof\n",
2021-02-18T19:50:50
Martin York :
API: Application Program Interface\n\nThis is the set of public types/variables/functions that you expose from your application/library.\n\nIn C/C++ this is what you expose in the header files that you ship with the application.\n\nABI: Application Binary Interface\n\nThis is how the compiler builds an application.\nIt defines things (but is not limited to):\n\n\nHow parameters are passed to functions (registers/stack).\nWho cleans parameters from the stack (caller/callee).\nWhere the return value is placed for return.\nHow exceptions propagate.\n",
2010-09-24T06:25:42
djna :
The API is what humans use. We write source code. When we write a program and want to use some library function we write code like:\nlong howManyDecibels = 123L;\nint ok = livenMyHills(howManyDecibels);\n\nand we needed to know that there is a method livenMyHills(), which takes a long integer parameter. So as a Programming Interface it's all expressed in source code. The compiler turns this into executable instructions which conform to the implementation of this language on this particular operating system. And in this case result in some low level operations on an Audio unit. So particular bits and bytes are squirted at some hardware. So at runtime there's lots of Binary level action going on which we don't usually see.\nAt the binary level there must be a precise definition of what bytes are passed at the Binary level, for example the order of bytes in a 4 byte integer, or the layout of a complex data structure - are there padding bytes to align some values. This definition is the ABI.",
2010-09-24T05:29:19