Civil Rights
Movements, leaders, victories and the continuing fight for equality.
q2K BHP
Black History Portal
THE BHP WIRE —
HIDDEN TRUTHS
What's New!
Explore the people, places, events, achievements, struggles and stories that shaped our journey.
Movements, leaders, victories and the continuing fight for equality.
Innovation, patents, science, technology and world-changing contributions.
Pioneers, champions, Negro Leagues, records, activism and excellence.
Meet the people whose lives, choices and achievements shaped the journey.
Black towns, communities, institutions and places where history happened.
Moments that changed communities, movements, institutions and the nation.
Mansa Musa was the ruler of the Mali Empire in West Africa. Details recorded here should be sourced; unknown information is left blank.
MORE →Reflects the personal views, recollections, and perspective of the author, Mike Davis.
This is a personal recollection on the Move fire on May 13, 1985
 | This article needs more citations. (November 2013) |
Binary-code compatibility (binary compatible or object-code compatible) is a property of a computer system, meaning that it can run the same executable code, typically machine code for a general-purpose computer central processing unit (CPU), that another computer system can run. Source-code compatibility, on the other hand, means that recompilation or interpretation is necessary before the program can be run on the compatible system.
For a compiled program on a general operating system, binary compatibility often implies that not only the CPUs (instruction sets) of the two computers are binary compatible, but also that interfaces and behaviours of the operating system (OS) and application programming interfaces (APIs), and the application binary interfaces (ABIs) corresponding to those APIs, are sufficiently equal, i.e. "compatible".
A term like 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 "binary compatible operating system" 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 drivers).
In other cases, a general porting of the software must be used to make non-binary-compatible programs work.
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.
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.
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 systems built around such processors. Full machine code compatibility would here imply exactly the same layout of interrupt service routines, I/O-ports, hardware registers, counter/timers, external interfaces and so on. For a more complex embedded system using more abstraction layers (sometimes on the border to a general computer, such as a mobile phone), this may be different.
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 architectures running the OSes have to be the same or compatible. Otherwise, programs can be employed within a CPU emulator or a faster dynamic translation mechanism to make them compatible.
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, is available that does that to some degree. The ReactOS development effort seeks to create an open-source, free software OS that is binary compatible with Microsoft'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 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.
Note that a binary compatible OS is different from running an alternative OS through virtualization or 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 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.
For another example, Mac OS X on the PowerPC had the ability to run Mac OS 9 and earlier application software through 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.[1][2]
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.
Source: Wikipedia. Article content is retrieved live through the MediaWiki API.
Binary-code compatibility (binary compatible or object-code compatible) is a property of a computer system, meaning that it can run the same executable code, typically machine code for a general-purpose computer central processing unit (CPU), that another computer system can run. Source-code compatibility, on the other hand, means that recompilation or interpretation is necessary before the program can be run on the compatible system. For a compiled program on a general operating system, binary compatibility often implies that not only the CPUs (instruction sets) of the two computers are binary compatible, but also that interfaces and behaviours of the operating system (OS) and application programming interfaces (APIs), and the application binary interfaces (ABIs) corresponding to those APIs, are sufficiently equal, i.e. "compatible". A term like 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 "binary compatible operating system" 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 drivers). In other cases, a general porting of the software must be used to make non-binary-compatible programs work. 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. 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.
Source-code compatibility (source-compatible) means that a program can run on computers (or operating systems), independently of binary-code compatibility and that the source code is needed for portability. The source code must be compiled before running, unless the computer used has an interpreter for the language at hand. The term is also used for assembly language compatibility, where the source is a human-readable form of machine code that must be converted into numerical (i.e. executable) machine code by an assembler. This is different from binary-code compatibility, where no recompilation (or assembly) is needed. Source compatibility is a major issue in the developing of computer programs. For example, most Unix systems are source-compatible, as long as one uses only standard libraries. Microsoft Windows systems are source-compatible across one major family (the Windows NT family, from NT 3.1 through Windows 11, or the family that includes Windows 95, Windows 98, and Windows Me), with partial source compatibility between the two families.
LessTif is a defunct free software reimplementation or clone of the Motif computer programming toolkit. The project aimed for full source- and binary-code compatibility with Motif. While this was not achieved, many Motif applications could run with LessTif or be compiled with it. As opposed to Motif, which was distributed until October 2012 under a proprietary license that could require the payment of royalties, LessTif was developed under the GNU Lesser General Public License (LGPL). The license of Motif was the main motivation for the development of LessTif. Following the release of the original Motif toolkit as open source under the LGPL in 2012, the LessTif project was discontinued.
An application binary interface (ABI) is an interface exposed by software that is defined for in-process machine code access. Often, the exposing software is a library, and the consumer is a program. An ABI is at a relatively low level of abstraction. Interface compatibility depends on the target hardware and the software build toolchain. In contrast, an application programming interface (API) defines access in source code, which is a relatively high-level, hardware-independent, and human-readable format. An API defines an interface at the source code level, before compilation, whereas an ABI defines an interface to compiled code. API compatibility is generally the concern for system design and of the toolchain. However, a programmer may have to deal with an ABI directly when writing a program in multiple languages or when using multiple compilers for the same language. A complete ABI enables a program that supports an ABI to run without modification on multiple operating systems that provide the ABI. The target system must provide any required libraries (that implement the ABI), and there may be other prerequisites.
Before the 1921 destruction of Tulsa’s Greenwood District, Black residents had created a remarkable center of business and community life. The district included stores, professional offices, entertainment venues and homes owned by Black citizens. Understanding Greenwood means learning what was built—not only what was burned.
MORE →Brown v. Board of Education in 1954.
