«

[Eagle of Fire]

16 and 8 bits (is there even 8 bits in PCs?) are not the problem at all. 16 bits always worked perfectly fine under XP and a good programmer would really have to explain to me in length why it is actually counter intuitive to have backward compatibility from one system to another. It is a simple matter of converting the already existing compatibility from previous OSes to the new one.

Why would you need a new compatibility setting for Win 98 if it was already built in XP? Same for 95 and 3.1... Etc.

64 bits not being compatible with 32 bits and lower is definitely done on purpose. Not only that, but compatibility actually already exist... You simply have to pay extra for them.

Then again, if the 32 bits programs you used in XP (the vast majority of PC users still use XP even today) would still work with 64 bits then you would have absolutely no incentive at all to purchase completely fine copies of the old programs you used to run, right?

[Japo]

Backwards compatibility was the one and only reason, weighting against a number of opposite considerations, that caused the industry to choose the AMD x64 architecture instead of the now extinct Itanium pushed by Intel. If the industry had been neutral towards backwards compatibility, not to mention if it had wanted to curtail it, the result would have been just the opposite.

Microsoft Windows in particular has a remarkable record on backwards compatibility, all things considered. As for 16-bit, according to what I've read, the main or only reason why 16-bit programs can't run natively in x64 is a technicality, that handles are 32-bit integers both in 32-bit and x64 versions of Windows (for backwards compatibility, I guess!), and so they can't be translated to old 16-bit handles.

Originally Posted by Eagle of Fire

64 bits not being compatible with 32 bits and lower is ...

... a wrong assertion. 32-bit programs do work in x64 OSes. And nowadays most new computers sold with Windows will have a x64 version, but most of the programs they will be used to run will probably be 32-bit. Nowadays still almost nobody's using or marketing 64-bit browsers or word processors etc. In the task manager of x64 Windows, 32-bit processes can be identified because their names have " *32" appended.

http://support.microsoft.com/kb/896456

[The Fifth Horseman]

Now look at it from THEIR point of view.
Most software released for 16-bit Windows systems has long since superceded by programs written for Win95 and later.
Getting any of it operational on x64 architecture involves additional investment into the software development and testing.
If someone has been running a piece of Win3 software for the past 16 years, this is unlikely to be by choice; these users are almost certainly a minority by now, so to the company it makes sense to charge them extra for features only they will be using.

There's nothing wrong with BWC, indeed, but there's only so far you can go until making sure everything is compatible with software released over last 25 years starts holding you back. Most users are unlikely to use any of the software from the first 10 years of that time frame - and your company has not been supporting the systems it was released for for most of the past decade either, so cutting down to "just" the ones from last 15 years does make sense.

[jonh_sabugs]

I wasn't refering to OS backward compatibility, but hardware instead. x86 and later architectures are pretty much a mess, what with all kinds of strange of memory set-ups, the weird real/protected mode switch, etc. These all are there to ensure legacy compatibility with older 16-bit Intel architectures. In having to carry all the previous resources, the architecture takes a hit in performance. For comparison, take the legacy architecture in PC and compare it to nVidia or ATI GPU architectures. The performance of the latter is astoundishingly superior.

Also, in OSes it's not as simply as reusing older code for compatibility. First, you can't simply attach a piece of code to your current system and hope it works, you have to test and do a through review to ensure no conflicts happen. Remember that this is kernel mode code, and basic memory structures like interrupt and paging tables may be accessed directly, and other things, which could cause havoc. Remember that these conflicts may happen in many levels, which can make the work complicated. Secondly, the older architecture resources may be slow. In this sense, to ensure proper compatibility, a system may be unable to fit older processes in new/more advanced memory/scheduling/other stuff managers, which can hamper the system as a whole.

That said, yes, windows does keep a reasonable backward compatibility, which is a merit for microsoft.

[dosraider]

* .... this post is only meant to add an extra layer of idiocy .... ignore it, THX ...*

Now that it seems that this really interesting topic -(and a discussion on the highest levels of intelligence ! )- goes towards backward compability, please let me add some thoughts.

Why can't the manufacturers and soft devs support my lovely 100% working Ensonic and SB ISA cards? I have boxes full of them lovely things, nothing wrong with them !! And no ISA slots on my new board!

Why can't they add a floppy conns on my newer motherboard? Have boxes full of them 5.25" and 3.5" drives and floppies laying around, and no connectors on my board !!

Why can't they add IDE conns on my new motherborad? Boxes full of them things, even working 5 MB ( yeah, really !!!) ones. Nothing wrong with them things !!! And no IDE connectors on my board!

And so on and so on .....

Oh yeah, almost forgot to mention those lovely S3 graph cards! But no slots on my new board!!

*Just ignore this post, please, THX*


And I want backwards CP/M compatibility !! Such lovely programs that it could run!!

OK OK OK, keep your calm, gonna leave you discuss without me.

[Eagle of Fire]

You guys still avoid the real question: why is it so hard to have backward compatibility if it's already been done?

[The Fifth Horseman]

Because "has been done" for one iteration of the host operating system does not mean it "has been done" in a way that will work for the subsequent ones.
At some point you're going to have changed or removed enough of the underlying technologies that BWC becomes only possible through complete emulation of the host OS.

[jonh_sabugs]

You have to eventually choose whether to work around older features or replace them with more elaborate ones. The former ties your hands and can have serious impact in system performance in the long run. As you replace them though, you lose compatibility and, yes, there will come a time where emulation is your only option.

[Scatty]

With all that said above, one thing can be clearly noticed with the computer hardware one can have today at hand - it's amazingly unflexible. And it's still sticking in "children's shoes", so to say. If you take the most advanced and complex computer there's to find in the world, well on Earth anyway - the human brain - you most probably won't find any such issues as backwards compatibility, as it is able to adapt to any circumstances and situations if necessary.

Which is probably the point of all problems - "hard"ware. There's been non-public development and testing of new form(s) of completely different, to what is officially available today, branch of computer(s) for quite some years now. Half-organic, biologically based processing to be more precise. But it's very hard to find anything on that in any news and it will probably still take many and many more years before it could even be considered widely available. If, and when it will, that might be turning point in backwards compatibility which we are experiencing with today's conventional hardware, not counting some of the other advantages it would have.

[dosraider]

In fact the hardest thing to implement or copy from the human brain is the "approximatively" concept.
Whilst every computing model can easily handle 1+1=2

The human brain has no problem handling 1+ a bit= something "a bit more than 1"
And if you add "some more" to it= probably 2, or more, or lesser.

From there on the human brain can work further on with "relative numbers", whilst any computer will block.

We're far from implementing a working 'fuzzy logic' in the computers, all that's been tried till now failed at some point or was restricted to a specific, extremely narrow situation.

Ah well, some day, mayhaps, or never..... I need a drink and a smoke.