Talk:Application binary interface

No pointers to many existing ABIs

there is a lack of pointers to many of existing ABIs — Preceding unsigned comment added by 84.88.50.86 (talk) 11:39, 9 March 2007 (UTC)

linux standard base

linux standard base is really nothing to do with ABI compatibility. needs removed but some research around ABI compatability to replace the current, erroneous statement would be good —Preceding unsigned comment added by 89.204.202.40 (talk) 22:35, 5 November 2007 (UTC)

statement about standardisation of ABI in Unices

the following statement

There have been several attempts to standardise the ABI such that software vendors may distribute one binary application for all these systems, however to date, none of these have met with much success.

requires some reference or qualification —Preceding unsigned comment added by 89.204.202.40 (talk) 22:38, 5 November 2007 (UTC)

merge

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result was merge EABI into Application binary interface. -- 128.2.247.37 (talk) 21:12, 6 February 2009 (UTC)

---

EABI article should not be merged with this article.

The EABI is a specific ABI. It does not make sense to make this high level discussion of what an ABI is have all of the different ABIs in it. —Preceding unsigned comment added by 63.111.126.138 (talk) 13:19, 5 May 2008 (UTC)

I agree that this high level discussion of "ABI" should not include all the information about specific ABIs. However, I suggest we merge Embedded Application Binary Interface into application binary interface anyway. EABI is not a specific ABI. (The ARM EABI, the PowerPC EABI, and the Motorola 8 and 16 bit EABI are specific ABIs). --68.0.124.33 (talk) 20:05, 1 June 2008 (UTC)

I guess I have to agree with you. I am just so used to thinking of the PPC EABI as the EABI. I wish there was a single equivalent for x86.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Apple ABI

Apple's operating system uses Objective-C for all its frameworks, which 'links' at runtime and does a bunch of clever things allowing you to call things with different numbers of argument and will dynamically change types of supplied arguments as necessary. So I don't think it technically can have ABI compatibility problems. Perhaps the person writing is complaining about API compatibility, i.e. Apple's habit of deprecating and then eliminating older APIs? — 89.145.102.10 (talk) 10:00, 30 June 2008 (UTC)

• I realize this is an old comment but this is an apples-oranges comparison, no pun intended. The features you speak of are not unique to OSX as those features are language specific and are portable across platforms and even CPU architectures. So those language features you speak of will also behave the same on Linux and Windows. ABI refers to how the OS interacts with a binary executable. Things like where machine code, data, and other bits reside inside the binary file. This ensures that binaries can compiled and linked using various compilers without needing to worry about compatibility. As long as you arrange your bits and bytes following the platforms ABI, your code will run and be able to call the OS and other code like dynamic libraries. The userspace ABI is always kept as stable as possible. This ensures that software like photoshop will always be able to run so long as the API's and runtimes it depends on are present. This is why I can still run 15 year old VB6 software on Windows 10 preview. Microsoft's ABI has not changed, they have not dropped the win32 API, and they have ported the VB6 runtime. An example of a major break in ABI would be the leap from OS9 to OSX. Even though the underlying hardware which OS9 and OSX ran on was essentially the same, the Kernel and userspace ABI was completely different. To ensure a smooth transition, Apple built the classic layer which is not an emulator but an ABI compatibility layer. Essentially they ported the OS9 ABI, API's, runtimes and libraries to OSX. Another example of an ABI compatibility layer would be WINE for Unix-like operating systems such as Linux and OSX. WINE is not an emulator (w.i.n.e. - get it?) but a (nearly)complete port of the underlying Windows ABI, API's, runtimes and libraries similar to the OSX classic layer. This allows actual windows binary code to execute on Linux or OSX unmodified, without the need for virtualization or porting code. If Apple drastically changed the ABI for some crazy reason, current OSX binaries would not be able to run, regardless of the language used. The only way to run old code would be to write an ABI compatibility layer OR rebuild the binary from source code. 47.23.29.18 (talk) 15:25, 24 November 2014 (UTC)

1) Not all APIs in macOS are from Objective-C frameworks; there are the UN*X APIs, the Core Foundation APIs, etc.. Change one of those APIs in a fashion that changes its ABI, and you beak ABI compatibility. I don't know which of those APIs are allowed in iOS/watchOS/tvOS software, but, if any are, the same applies there.

2) If you remove a framework from macOS/iOS/watchOS/tvOS, you'll break ABI compatibility. Removing an Objective-C method will also break ABI compatibility. Guy Harris (talk) 21:46, 4 May 2017 (UTC)

ABIs vs. ISAs

What's the difference between an Embedded ABI and an ISA (instruction set)? PowerPC and ARM are listed under both EABI and ISAs. Is this an error? --Fishburd (talk) 05:54, 18 November 2009 (UTC)

ABI - application binary interface. This defines how the operating system looks at an executable file to know where things like data such as strings exist and where executable machine code resides. An example of how the ABI works would be the the entry point where the OS steps in and starts running your application. In many languages that would be main(). This ensures that code built by a variety of compilers and even libraries can interact with the OS and other compiled code. The OS defines the ABI and is independent of an ISA like ARM, PowerPC, MIPS or x86_64. Platforms can also have EABI's for embedded use where full blown operating systems like Linux are not used but instead run flat binary's or single process, multi threaded RTOS's. It ensures that code built by a variety of compilers and libraries can interact without the overhead of a complex OS which usually defines an ABI. So instead of a developer having to reinvent the wheel and design an ABI for embedded use, they can simply use the pre-defined and standardized EABI. Takes a lot of work off the developers plate and moves it into the compiler. The ISA or instruction set architecture defines the CPU itself. It is the job of the compiler to know how to compile and then link code for your ISA. 47.23.29.18 (talk) 15:52, 24 November 2014 (UTC)

If you look at the System V Release 4 ABIs, there's a "common" ABI, which, for example, describes the ELF executable image format and lists the functions in the ABI, and a set of supplements for particular instruction sets, giving information such as the sizes of data types, layout rules for data structures, and procedure call conventions, and the way code for that instruction set is represented in an ELF executable image (for example, the types of relocation, which are instruction set-dependent). See the System V Release 4.1 ABI and the i386 supplement to the SVR4.1 ABI.

The ABI supplement for a given instruction set doesn't itself describe the instruction set; it refers to the official documentation for the instruction sets, as many instruction sets for which there are SVR4 ABIs are also supported by OSes other than SVR4. Guy Harris (talk) 20:27, 24 November 2014 (UTC)

Issues

I see a few glaring issues with this article.

1. I don't see any clear explanation of the "binary" nature of the ABI
2. I don't see any discussion of what the most common ABIs are
3. I only see one clear example: iBCS
4. I don't see any discussion of virtual machines, and whether or not bytecode or a VM runtime would be considered an ABI — Preceding unsigned comment added by 75.139.254.117 (talk) 00:57, 21 November 2016 (UTC)

I've found another issue. There is no real discussion of naming concerns within ABIs, in particular, no discussion of the role of symbols. I've added a couple links, but can't do much more. 75.139.254.117 (talk) 09:01, 13 January 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Application binary interface. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070121183413/http://www.linuxdevices.com/news/NS9048137234.html to http://linuxdevices.com/news/NS9048137234.html
• Added archive https://web.archive.org/web/20070331193917/http://www.linuxdevices.com/articles/AT5920399313.html to http://linuxdevices.com/articles/AT5920399313.html
• Added archive https://web.archive.org/web/20080528070803/http://www.x86-64.org/documentation.html to http://www.x86-64.org/documentation.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:52, 8 July 2017 (UTC)

What's an SBI?

--117.195.63.111 (talk) 12:47, 10 December 2017 (UTC)

System Binary Interface, but what is it? --117.195.63.111 (talk) 12:50, 10 December 2017 (UTC)

If this concise explanation of API vs. ABI is correct, can be a better way to explain what an ABI is

An Application Program Interface is an abstract view of the system internals, on the other hand an Application Binary Interface is the standardized systems concrete data structures implementation.

Does an ABI also standardize how procedures should be implemented? for example to be or not re-entrant code or o be forced to use some global variables.

What does it mean abstract vs. concrete? An abstract data type is accessed through function prototypes independent of the data representation chosen to implement the data type. For example: a stack of T type objects, is defined and also accessed via its constructors and selectors.

TStack push(T x, TStack s)

TStack empty

could be a prototype for the constructors push and empty.

T top(TStack s)

must correspond to the specification top(push(x,s))=x and top(empty)=Error

TStack pop(TStack s)

must correspond to the specification pop(push(x,s))=s and pop(empty)=Error

Bool isempty(TStack s)

must correspond to the specification isempty(push(x,s))=False and

isempty(empty)=True.

The concrete implementation may define the TStack data type with an array, or a list (is isomorphic to a list).

The API hides the actual representation (an array, list, ...) The ABI shows the actual representation.

If this is correct, could someone please work the above explanation apporting more details to what does an what doesn't comprise the ABI, to have a more concise explanation of ABI in the article. — Preceding unsigned comment added by 201.124.191.35 (talk) 14:33, 10 August 2020 (UTC)