Talk:Application binary interface

Computing Start‑class Mid‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Start	This article has been rated as Start-class on Wikipedia's content assessment scale.
Mid	This article has been rated as Mid-importance on the project's importance scale.

untitled

hello

there is a lack of pointers to many of existing ABIs

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]