7 Jun
2023
7 Jun
'23
12:01 a.m.
> "The only possible way to have 100%
compatability is copyright infringement. But, you can certainly come up with something
that is similar enough to do what you need."
On Tue, 6 Jun 2023, Paul Koning wrote:
That's not always true. Another way to get it is
to implement from sufficiently high quality specifications. The DIX Ethernet spec, and
the DECnet specs, are examples where if you do what they say you will have an
interoperable implementation.
Unfortunately that level of quality is not common, but it can and has been done.
Well, our discussion will be hindered by variations in the definitions of
compatability.
And, we are discussing it in the context of IBM 5150!
A perfect implementation of the specification is certainly one definition,
and should certainly give you something similar enough to do what you
need. In MOST cases.
But, what if the specification itself is not perfect?
If we, instead, define "100% compatability" as always behaving exactly the
same as the original, we might have problems.
With something like the IBM PC, you might still run up against a
situation where somebody has exploited a bug, and the perfect
implementation is therefore not completely the same as the real world
example.
We have to agree first about whether 100% compatability means a perfect
mplementation of the specification, or whether 100% compatability means
"bug for bug compatability".
MY definition of 100% includes "bug for bug compatability".
"Do you want it completely compatible, or do you want it to work RIGHT?"
I can't off the top of my head come up with any GOOD examples, such as why
you might WANT to do any of the specific floating point divisions that
show that bug in certain early Pentiums, but should we call it completely
compatible with THAT model if it fails to give that particular wrong
result?
but...
In the screen capture section of XenoFont, the full 4000 bytes of text mode
video memory could not be done fast enough (unless I did it in sections
and synchronized when it happened) without a clash that produced a
mometary sparkle of "static". I declared that to be a FEATURE, and said
that that was "the flash going off" to tell you when the image got
captured. :-) And, believe it or not, some users LIKED that! A machine
that is enough faster than a 5150 to NOT get that "interference" might be
BETTER, but not behaving exactly the same.
One of my students once was asking about the "freeze" of 5150 BASIC during
"garbage collection" and wondered about using that to get random
unexpected pauses and breaks for users doing long intensive tasks!
--
Grumpy Ol' Fred cisin(a)xenosoft.com