Bug compatibility. Computer hardware or software is said to be bug compatible if it exactly replicates an undesirable feature of a previous version. The phrase is found in the Jargon File.

An aspect of maintaining backward compatibility with an older system is that such systems' client programs often do not only depend on their specified interfaces but also bugs and unintended behaviour that must also be preserved by the newer replacement. Besides the significantly higher complexity that needs to be maintained during the natural evolution of the code or interface, it can sometimes cause performance or security issues, and the inconsistencies in the behaviour of interfaces can sometimes lead to new bugs in the software using it, creating difficult to resolve multi-directional cross dependencies between various pieces of code.

Examples

DOS
Examples can be found in MS-DOS/PC DOS:
When MS-DOS/PC DOS 3.1 and higher (including Windows 9x) and OS/2 detect certain FAT OEM labels, they do not trust some BIOS Parameter Block (BPB) values and recalculate them from other disk geometry parameters in order to work around several off-by-one calculation errors caused by some of their formatter software under earlier issues of these systems. While this undocumented behaviour allows them to cope with these incorrectly formatted volumes specifically, it limits the flexibility of disk geometries they can work with in general and can cause them to trash validly formatted volumes created by third-parties if they deviate from the defaults used by Microsoft and IBM.
When MS-DOS/PC DOS 5.0 and higher are running on 286 or higher processors, the resident executable loader contains code specially designed to detect and fix certain widespread applications and stub loaders (such as programs linked with older versions of Microsoft's EXEPACK or Rational Systems' 386 DOS extenders) by patching the loaded program image before executing it. Under certain conditions an underlying DOS also patches Windows (WINA20.386).

Over the course of development, DR-DOS also had to be modified to not only emulate many undocumented peculiarities and undesirable properties of MS-DOS and PC DOS (like having to use certain misleading filenames such as IBMBIO.COM, IBMDOS.COM or COUNTRY.SYS for files which do not follow the specs for executables under DOS, or having to introduce a directory path length-limited Current Directory Structure (CDS) internally), but also actual bugs in the kernel and several drivers, in order to make certain other drivers and applications run on DR-DOS, when they were tested on specific versions of MS-DOS only.

Windows
Windows, which has traditionally emulated many old system bugs to allow older low-level programs to run, is another example. As a result, Wine, which makes it possible to run many Windows applications on other platforms, also needs to maintain bug compatibility with Windows.

Other
During development of its IBM PC compatible, Compaq engineers found that Microsoft Flight Simulator would not run because of what subLOGIC's Bruce Artwick described as "a bug in one of Intel's chips", forcing them to make their computer bug-compatible with the IBM PC. Another hardware example is found in the design of the IBM Personal Computer/AT A20 address line to emulate the behaviour in older processors.

Microsoft Excel has always had a deliberate leap year bug, which falsely treats 29 February 1900 as an actual date, to ensure backward compatibility with Lotus 1-2-3.

Hyrum Wright, an engineer at Google, talks about this problem that he observed firsthand while working on C++ core libraries. It was Titus Winters, also an engineer at Google, who popularized this concept on a larger scale as "Hyrum's Law".

The HTTP referer header is a misspelling of the word referrer. It was a mistake in the original web proposal, and was kept for compatibility.

See also

 AARD code
 Plug compatible
 Software bug
 API

Notes

References

Software bugs
Backward compatibility