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 and APIs, and the 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.
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.