[Simh] Compatibility you can use Was: VAX/VMS

[lists at openmailbox.org]

On Mon, 22 Feb 2016 10:07:10 +0100
Johnny Billquist <bqt at softjar.se> wrote:

> On 2016-02-22 07:07, lists at openmailbox.org wrote:
> > However, we see that Intel's hardware compatability is only of academic
> > interest because virtually none of the OS or apps for several
> > generations of Intel chips runs on any remotely current Intel-hosted
> > OS. I already pointed out many day-to-day incompatibilities between
> > code running 32 bit vs. 64 etc. on Intel today. You can blame Microsoft
> > or Bell Labs or even Richard Stallman but Intel has certainly been
> > involved intimately with much OS development on its platform and has
> > continued to bork time after time.
> 
> You can't seriously mean that you think that a 32-bit application and a 
> 64-bit application would be expected to be compatible with each other?
> I would expect the 32-bit code to work in 32-bit mode, but having it 
> work if you are in 64-bit mode is a ridiculous expectation.

Really? It works fine on IBM's z/OS.

It seems ridiculous to me that you think it shouldn't. This is what I have
been saying. IBM moved from 24 bit to 31 bit to 64 bit and everything still
works. No expanded footprint, no duplicate libraries, no problem.

> And the OS should detect that it's a 32-bit application, and set the
> system up for running such an application with the CPU set the right way.
> The CPU can do it. If things fail because the OS does things wrong, you
> should not blame the CPU.

I didn't blame the CPU. I said Intel's compatibility is really only
academic and has no actual value in most cases:

> > We all know at the end of the day people buy hardware to run apps. We
> > also know most of the apps ever written for Intel are no longer useful
> > even if you could boot obsolete OS and run them. Any meaningful notion
> > of compatibility has to include the ability to continue to run your
> > apps on every new OS and hardware generation. With Intel you can't. You
> > can point all the fingers you want but that is the reality in the Intel
> > environment.
> >
> > In practice, several decades of software and development investment,
> > applications, and OS go up in smoke with each new generation of Intel
> > chips. In contrast IBM has preserved the customer's investments in
> > technology, development, and applications. IBM takes the loss on the OS
> > development but the customer's applications continue to run forever on
> > the latest platform. Intel is an ecosystem of churning, turmoil and
> > waste. That's something only an accountant could love.
> 
> I think you are confusing the backware compatibility in the processor, 
> which is working just fine, with the less than stellar backward 
> compatibility in various OSes along the way, which is nothing you should 
> blame on Intel.

I'm comparing Intel's shortcomings and consistent track record of borks to
what I have seen done well by IBM. It was all there for Intel and the
developers who write for it to see how things were done right, but they
kept making mistakes. There's just no excuse for most of the decisions.
Except possibly from Intel's accounting viewpoint as was discussed.

> Like I said, grab an old DOS floppy, pop it into a a new machine, and it 
> will boot. That's a fact.

See above. That doesn't really help the 99.9 bar percent of people that
spent money on DOS and DOS apps and countless other OS and software that
don't run on Windows on modern hardware.

> > As has been noted code from virtually the beginning of OS/360 still runs
> > today and furthermore can happily coexist with newly written apps
> > without any hoop jumping like relinking, recompiling, or needing
> > multiple libraries. It just continues to work. Software compatibility
> > beats hardware compatibility any day of the week. What's important is
> > that your application and development investment continues to be viable
> > on each new hardware platform with each new OS. That is what IBM has
> > done, and it is a combination of hardware and software designed to work
> > together and boy does it ever, as opposed to a pizza with everything on
> > it spoiled by too many chefs.
> 
> Yes. IBM has done an excellent job.

It's not just excellent in the abstract. It's the best example we have in
the history of computing of how good engineering and upward compatability
as fundamental design principles preserves the investment in software and
development skills. Virtually everything that ever ran since the beginning
of OS/360 in 1964 still runs on the latest hardware and OS here in 2016,
all without recompiling or relinking or duplicate libraries, etc.