<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>http://debianws.lexgopc.com/wiki143/index.php?action=history&amp;feed=atom&amp;title=Binary-code_compatibility</id>
	<title>Binary-code compatibility - Revision history</title>
	<link rel="self" type="application/atom+xml" href="http://debianws.lexgopc.com/wiki143/index.php?action=history&amp;feed=atom&amp;title=Binary-code_compatibility"/>
	<link rel="alternate" type="text/html" href="http://debianws.lexgopc.com/wiki143/index.php?title=Binary-code_compatibility&amp;action=history"/>
	<updated>2026-05-05T23:13:05Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.43.1</generator>
	<entry>
		<id>http://debianws.lexgopc.com/wiki143/index.php?title=Binary-code_compatibility&amp;diff=5914260&amp;oldid=prev</id>
		<title>imported&gt;Pink Bee: ce #article-select-source-editor</title>
		<link rel="alternate" type="text/html" href="http://debianws.lexgopc.com/wiki143/index.php?title=Binary-code_compatibility&amp;diff=5914260&amp;oldid=prev"/>
		<updated>2024-04-28T22:48:58Z</updated>

		<summary type="html">&lt;p&gt;ce #article-select-source-editor&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;{{Refimprove|date=November 2013}}&lt;br /&gt;
{{short description|Ability of a computer system to run the same code as another computer system}}&lt;br /&gt;
&lt;br /&gt;
&amp;#039;&amp;#039;&amp;#039;Binary-code compatibility&amp;#039;&amp;#039;&amp;#039; (binary compatible or [[object code|object-code]] compatible) is a property of a [[computer system]], meaning that it can run the same [[executable|executable code]], typically [[machine code]] for a [[Computer|general-purpose computer]] [[central processing unit]] (CPU), that another computer system can run. [[Source-code compatibility]], on the other hand, means that [[code compilation|recompilation]] or [[interpreter (computing)|interpretation]] is necessary before the program can be run on the compatible system.&lt;br /&gt;
&lt;br /&gt;
For a compiled program on a general operating system, binary compatibility often implies that not only the CPUs ([[Instruction set architecture|instruction sets]]) of the two computers are binary compatible, but also that interfaces and behaviours of the [[operating system]] (OS) and [[application programming interface]]s (APIs), and the [[application binary interface]]s (ABIs) corresponding to those APIs, are sufficiently equal, i.e. &amp;quot;compatible&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
A term like [[Backward compatibility|backward-compatible]] usually implies object-code compatibility. This means that newer computer hardware and/or software has (practically) every feature of the old, plus additional capabilities or performance. Older executable code will thus run unchanged on the newer product. For a compiled program running directly on a CPU under an OS, a &amp;quot;binary compatible operating system&amp;quot; primarily means [[application binary interface]] (ABI) compatibility with another system. However, it also often implies that APIs that the application depends on, directly or indirectly (such as the [[Windows API]], for example), are sufficiently similar. Hardware (besides the CPU, such as for graphics) and peripherals that an application accesses may also be a factor for full compatibility, although many hardware differences are hidden by modern APIs (often partly supplied by the OS itself and partly by specific [[device driver]]s).&lt;br /&gt;
&lt;br /&gt;
In other cases, a general [[porting]] of the software must be used to make non-binary-compatible programs work.&lt;br /&gt;
&lt;br /&gt;
Binary compatibility is a major benefit when developing computer programs that are to be run on multiple OSes. Several [[Unix]]-based OSes, such as [[FreeBSD]] or [[NetBSD]], offer binary compatibility with more popular OSes, such as [[Linux]]-derived ones, since most binary executables are not commonly distributed for such OSes.&lt;br /&gt;
&lt;br /&gt;
Most OSes provide binary compatibility, in each version of the OS, for most binaries built to run on earlier versions of the OS.  For example, many executables compiled for [[Windows 3.1]], [[Windows 95]] or [[Windows 2000]] can also be run on [[Windows XP]] or [[Windows 7]], and many applications for [[DOS]] ran on much newer versions of Windows up to Windows 10 for as long as the [[NTVDM]] was supported.&lt;br /&gt;
&lt;br /&gt;
== Binary compatible hardware ==&lt;br /&gt;
For a digital processor implemented in hardware, binary compatibility means that (a large subset of) [[machine code]] produced for another processor can be correctly executed and has (much) the same effect as on the other processor. This is quite common among many processor families, although it is rather uncommon among the ubiquitous small [[embedded system]]s built around such processors. Full machine code compatibility would here imply exactly the same layout of [[Interrupt handler|interrupt service routine]]s, I/O-ports, [[hardware register]]s, counter/timers, external interfaces and so on. For a more complex embedded system using more [[abstraction layer]]s (sometimes on the border to a general computer, such as a mobile phone), this may be different.&lt;br /&gt;
&lt;br /&gt;
== Binary compatible operating systems ==&lt;br /&gt;
Binary compatible operating systems are OSes that aim to implement binary compatibility with another OS, or another variant of the same brand. This means that they are ABI-compatible (for [[application binary interface]]). As the job of an OS is to run programs, the [[instruction set architecture]]s running the OSes have to be the same or compatible.  Otherwise, programs can be employed within a [[Emulator|CPU emulator]] or a faster [[Just-in-time compilation|dynamic translation]] mechanism to make them compatible.&lt;br /&gt;
&lt;br /&gt;
For example, the [[Linux kernel]] is not compatible with Windows. This does not mean that Linux cannot be binary compatible with Windows applications. Additional software, [[Wine (software)|Wine]], is available that does that to some degree. The [[ReactOS]] development effort seeks to create an [[open-source software|open-source]], [[free software]] OS that is binary compatible with [[Microsoft|Microsoft&amp;#039;s]] [[Windows NT]] family of OSes using Wine for application compatibility and reimplementing the Windows kernel for additional compatibility such as for drivers whereas Linux would use Linux drivers, not Windows drivers.  [[FreeBSD]] and other members of the [[Berkeley Software Distribution|BSD]] family have binary compatibility with the [[Linux kernel]] in [[usermode]] by translating Linux system calls into BSD ones.  This enables the application and libraries code that run on [[Linux]]-based OSes to be run on BSD as well.&lt;br /&gt;
&lt;br /&gt;
Note that a binary compatible OS is different from running an alternative OS through [[Hardware virtualization|virtualization]] or [[Emulator|emulation]], which is done to run software within the alternative OS in the case when the host OS is not compatible. Sometimes virtualization is provided with the host OS (or such software can be obtained), which effectively makes the host OS compatible with programs. For example, [[Windows XP Mode]] for [[Windows 7]] allows users to run a [[64-bit computing|64-bit]] version of Windows 7 and enable old software to still work in a [[32-bit]] virtual machine running [[Windows XP]]; [[VMware Workstation]]/[[VMware Fusion]], [[Parallels Workstation]], and [[Windows Virtual PC]] allow other OSes to be run on Windows, Linux, and macOS.&lt;br /&gt;
&lt;br /&gt;
For another example, [[Mac OS X]] on the [[PowerPC]] had the ability to run [[Mac OS 9]] and earlier application software through [[Classic Environment|Classic]]—but this did not make Mac OS X a binary compatible OS with Mac OS 9. Instead, the Classic environment was actually running Mac OS 9.1 in a [[virtual machine]], running as a normal process inside of Mac OS X.&amp;lt;ref&amp;gt;{{cite web|archiveurl=https://web.archive.org/web/20020802034101/http://developer.apple.com/macosx/architecture/|archivedate=August 2, 2002|url=https://developer.apple.com/macosx/architecture/|title=Mac OS X System Architecture|year=2002}}&amp;lt;/ref&amp;gt;&amp;lt;ref&amp;gt;{{cite book|title=Mac OS X Internals: A Systems Approach|last=Singh|first=Amit|at=Section 2.11.8: Classic|publisher=[[Addison-Wesley]]|isbn=0-321-27854-2|date=June 29, 2006|quote=Classic Startup is a Mach-O application that runs Mac OS 9 within its address space. It provides a hardware abstraction layer between Mac OS 9 and Mac OS X by virtualizing traps, system calls, and interrupts. It runs in a protected memory environment, with multiple Mac OS 9 processes within it layered on top of a single Mac OS X BSD process.}}&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==See also==&lt;br /&gt;
* [[Backward compatibility]]&lt;br /&gt;
* [[Application binary interface]] (ABI)&lt;br /&gt;
* [[Computer compatibility]]&lt;br /&gt;
* [[Bug compatibility]]&lt;br /&gt;
* [[Plug compatibility]]&lt;br /&gt;
* [[Video game remake]]&lt;br /&gt;
* [[Multi-architecture binary]]&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
{{reflist}}&lt;br /&gt;
&lt;br /&gt;
==External links==&lt;br /&gt;
* [http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ KDE Techbase Policies] – a compendium of C++ development rules of thumb (with [http://techbase.kde.org/Policies/Binary_Compatibility_Examples some examples]) for not breaking binary compatibility between releases of a library.&lt;br /&gt;
* [https://github.com/lvc?tab=repositories ABI Analysis Tools]{{snd}} a set of open-source tools for analysis of ABI and backward binary compatibility implementing KDE Techbase Policies&lt;br /&gt;
&lt;br /&gt;
{{Application binary interface}}&lt;br /&gt;
&lt;br /&gt;
[[Category:Backward compatibility]]&lt;br /&gt;
[[Category:Computing terminology]]&lt;br /&gt;
&lt;br /&gt;
[[de:Kompatibilität (Technik)#Binärkompatibilität]]&lt;/div&gt;</summary>
		<author><name>imported&gt;Pink Bee</name></author>
	</entry>
</feed>