Contents 1 Irrelevant 2 Promotion 3 Upward is Backward, Downward is Forward 4 Google says otherwise.... upward = forward and downward = backward 5 Difference between 1+3? 6 Native and Emulated 7 Master System and Game Gear 8 ColecoVision and Intellivision 9 Funny stuff 10 Hysterical raisins 11 The words Client and Server should be removed 12 Backward compatibility vs emulation 13 x86 14 "Backward compatibility" of applications

[edit] Irrelevant

the entire examples section may have led to have interesting reading, but is completely irrelevant and should be removed imho. —Preceding unsigned comment added by 82.41.135.70 (talk • contribs) 20:46, 23 November 2008

[edit] Promotion

So that this article doesn't promote any specific products, and to make the description more generic (so that this page won't need to be updated when the mentioned products go out of style), I suggest that we remove the product names from this article. I am happy to do it, I just wanted to know if anybody cared. —Preceding unsigned comment added by Kookiepus (talk • contribs) 02:21, 30 March 2005

[edit] Upward is Backward, Downward is Forward

After conducting some research into the matter, it appears that Downward Compatibility actually means Forward Compatibility. Refer to the following Sun documents for examples of this usage.

http://java.sun.com/javase/compatibility_j2se1.4.1.html

Here is an excerpt.

"The Java 2 SDK, v1.4.1 is upwards binary-compatible with Java 2 SDK, v1.4.0 except for the incompatibilities listed below. This means that, except for the noted incompatibilities, class files built with version 1.4.0 compilers will run correctly in the Java 2 SDK, v1.4.1."

Sun's documents always refer to the earlier versions as the "upward" versions; hence, in the sense of compatibility, "upward" is "backward" and "downward" is "forward".

Suggest changing the redirects appropriately.

[edit] Google says otherwise.... upward = forward and downward = backward

Plug _"backward compatible" "downward compatible"_ into Google and you will see what I mean.

Also, I didn't check the other languages, but the Japanese entry for backward is "kai" which corresponds to downward. Likewise, the Japanese entry for forward is "joi" which corresponds to upward.

Either way, this needs to be clarified and unified across languages.

Kylethewright (talk) 18:22, 14 December 2007 (UTC)

[edit] Difference between 1+3?

Is there any material difference between meaning 1 and meaning 3? (or meaning 2, for that matter) --Dtcdthingy 16:00, 24 July 2005 (UTC)

[edit] Native and Emulated

I think this article should point out the difference between native and emulated backwards compatibility. For example the XBOX 360 uses emulated backwards compatibility while the Playsation 360 supposedly is natively backwards compatible.

On a further note on that the extent of backwards compatibility should be covered in the main article. In some of the examples, the indicated system provides full (software and hardware) backwards compatibility, but some only provide software backwards compatibility as the hardward lacks all the features that the original hardware possesed (ie. Playstation 3 controllers lack rumble functionality)

Has a grammarian read this??

Hopiakuta 22:43, 20 July 2006 (UTC)

[edit] Master System and Game Gear

The Sega Game Gear can play Sega Master System games by adding a "Master Gear".

Does this actually count as backwards compatibility? I don't think of the Game Gear as a successor to the Master System. After all, weren't they roughly technologically equivalent? From what I remember, the versions of games released for each were the same, or at least very similar. I suppose you could say that the Game Gear was a successor in that it was a much more compact version of the Master System, but I still think this is just compatibility (I'd call it 'sideways compatibility', but that's probably a bit redundant). — TheJames 15:33, 20 November 2006 (UTC)

[edit] ColecoVision and Intellivision

Backward compatibility is the special case of compatibility in which the new server has a direct historical ancestral relationship with the old server. If this special relationship does not exist then it not usually spoken of as "backward" compatibility but is instead just "compatible" — a consistent interface allowing interoperability between components and products that were each developed separately.

[...]

• The Colecovision can play Atari 2600 games by adding the "Expansion Module #1".
• The Intellivision can play Atari 2600 games by adding the "System Changer".

OK, I'm not particularly familiar with either of those systems, but since neither were manufactured by Atari, could they really be said to have a 'direct historical ancestral relationship'? — TheJames 15:33, 20 November 2006 (UTC)

[edit] Funny stuff

When I searched for "aidepikiw" in Google I got this article as the first result! --WikiSlasher 14:34, 3 April 2007 (UTC)

[edit] Hysterical raisins

Added section on hysterical raisins here, to fix a link that once existed to hysterical raisins, which was since deleted. It feels a little out of place, though: I wouldn't argue a revert, or at least a better rewording. —The preceding unsigned comment was added by DewiMorgan (talk • contribs) 22:16, 14 May 2007 (UTC).

[edit] The words Client and Server should be removed

The words 'client' and 'server' in their normal IT usage are not relevant here, or at best confusing). People, like me, can be misled into thinking that backward compatability is only applicable in a client-server environment (eg. client = browser, server = webserver) which is clearly not true.

• People who have studied computer science have no trouble understanding the words client and server in the abstract sense that is used in the article. If anything, using client and server makes it more obvious than any other words I can think of to describe the "things involved in a relationship of backwards compatibility". What other words would you suggest? Note that without any further qualification the word "server" is an abstract concept and does not denote any specific kind of server, so I don't see why anyone should be confused.

• Agreeing with use of client/server terminology. Makes the structure of backward compatability very clear.

• Many of the "examples" of backward compatibility listed, however, are incorrect in that respect. They cite, for example, newer video game systems as being backward-compatible with older games. Technically, the newer video game system is compatible with the older vides game system, not with its games. This particular loose-language error prevades this article.

[edit] Backward compatibility vs emulation

So someone had edited my contribution saying that this article does not deal with emulation--that's fine. But what perplexes me is that he kept Mac OS X's thing but deleted Wine. Seems completely backwards to me. Plus it might be put into question weather or not DOSBox should be counted here; even though it emulates a 486 PC and has the possibility of emulating operating systems other than the built-in one, most people simply use it to run DOS games; especially on Windows NT where the DOS subsystem is unable to run most games. For now, I'm just leaving the Windows NT subsystems and Wine notes, both of them are designed to simulate the ABIs of other systems without emulating any hardware (or even an operating system). --Mike 22:56, 12 October 2007 (UTC)

That someone was me, so it's more than appopriate to call me out on the edit rather than be circumspect. To be honest, I nearly pitched the "Classic" environment addition, as well. The reason I retained it (and the NT-related writing) is that they are both very clear examples of planned backward compatibility along/within product lines. The WINE/DosBox/QEMU-VMWare-VirtualPC additions discussed emulation in terms of product replacement. It's probably a difference without a distinction now that I review the positioning of this article's subject from the head downwards. I do think this article needs further expansion to balance the examples, but that cannot be laid at your feet. D. Brodale 02:37, 13 October 2007 (UTC)

Sorry if I sounded harsh against you, I was simply confused on the matters of the edit. Having a more precise definition of backward compatible on Wikipedia would be difficult, since there's so many conflicting definitions of it anyway (eg, people saying the Wii is "backwards compatible" with the NES, even though it really uses emulation and ROM images). --Mike 20:39, 17 October 2007 (UTC)

I don't take it as harsh at all, as I provided my rationale for the original removals and can see your POV as well. If an adequate definition cannot be supplied, I think that may point to a larger issue in terms of this article's scope that should be addressed. D. Brodale 21:20, 17 October 2007 (UTC)

[edit] x86

# All of Intel x86 processors – Core 2, Core, Pentium 4, Pentium III, Pentium II, Pentium Pro, Pentium, 80486, 80386, 80286, 80186 and 8086 – are backward compatible with their predecessors, because they can execute programs written for an earlier processor.

It strikes me that this doesn't represent backwards compatibility at all. The fact that x64 processors natively support x86, sure... but the fact is all x86 processors are just that, x86 processors. It's not 'backwards compatibility', it's the same instruction set. -Rushyo ^Talk 17:34, 4 September 2008 (UTC)

[edit] "Backward compatibility" of applications

The notion of backward compatibility of an application with regard to its ability to save a file in v1 format is confusing, and contradicts the definition at the beginning of the article.

Backward compatibility should not be confused with an application's supporting two different versions of a certain format. An application can support two more or less different versions of a file format, or even two totally unrelated file formats, by implementing the two format specifications separately. This has nothing to do with backward compatibility. The use of the term "backward compatibility" should be limited to the cases where **any** v2 implementation (not just one specific software product) is able to **read** a v1 file essentially without being aware that it is a v1 file (or, anyway, without doing anything special or without having to first determine the version of the file). The point of backward compatibility is that any **consumer** implementations of the v2 specification can be widely deployed without any risk. (Forward compatibility, on the other hand, ensures that any **producer** implementations of the v2 specification can be widely deployed without any risk.) If an application is able to write both a v1 file and a v2 file, this just means that the application implements both versions of the format specification as a producer, and not that the v2 specification is backward compatible. —Preceding unsigned comment added by 216.86.58.66 (talk) 19:53, 11 September 2009 (UTC)