!Re: Nuke Redmond!

From: Richard Erlacher <edick_at_idcomm.com>
Date: Fri Apr 7 21:52:30 2000

please see embedded comments below.

Dick

----- Original Message -----
From: Sean 'Captain Napalm' Conner <spc_at_armigeron.com>
To: <classiccmp_at_classiccmp.org>
Sent: Friday, April 07, 2000 7:12 PM
Subject: Re: !Re: Nuke Redmond!


> It was thus said that the Great Richard Erlacher once stated:
> >
> > > The similarities of MS-DOS to CP/M are mostly internal. In looking
over
> > > the list of OS functions between the two, the first 36 functions of
each are
> > > the same, with a few notable exceptions where the concept don't match
> > > (MS-DOS for example does not have an IOBYTE).
> >
> > What of those things internal would you have had them leave out in order
to
> > be more different from CP/M, which was a VERY popular OS at the time,
> > without removing its functionality. Since the features to which you
refer
> > are internal, I assume you have precice citations of common source code,
> > right? They're certainly not obvious to me in my role as a fairly
frequent
> > user.
>
> Well, the question on the table was the similarities between CP/M and
> MS-DOS which you didn't see outright because you only noticed the external
> side of each (user commands). All I did was show that the similarites
were
> a bit deeper than just the user commands.
>
> And to make the comparrison all I had to do was lookup the operating
> system functions between the two. For example, the first twelve
functions:
>
> # CP/M MS-DOS
> ---------------------------------------------------------------
> 1 Read console Character input with echo
> 2 Write console Character output
> 3 Read reader Auxilliary input
> 4 Write punch Auxilliary output
> 5 Write list Printer output
> 6 Direct console I/O Direct console I/O
> 7 Determine IOBYTE Unfiltered character input w/o echo
> 8 Set IOBYTE Character input w/o echo
> 9 Print buffer Display string
> 10 Read buffer Buffered keyboard input
> 11 Return console status Check input status
> 12 Return version Flush input buffer then input
>
> It's hard to say how I would design an OS for CP/M class (or early
MS-DOS
> class) machines; hind sight and all that. And I'm not even saying it was
> wrong for Tim Patterson to model the OS calls after CP/M. After all,
that's
> what he knew.
>
I'd say that was what he knew was popular and well-understood. Back then it
was more important that it be easy to learn and use than to be unique. If
Tim Patterson patterned his call list after CP/M it was probably because
he'd been asked to cook up something that would appeal to the typical CP/M
user. Today, there's no looking at the code and bitching about the call
sequence or any other such minutiae, but it's the "look and feel" that gets
the judges excited enough to rule agains you if you've preseved it.

If you were thumping Billy Gates and his friends by hinting that they simply
bought something and filed off the rough edges and nibbled at the edges
where it didn't fit, well, that's legitimate business. You might not see
that as innovation (just to bring this discussion back to where we left the
original thread) then keep in mind that those of us who use the software
every day care a lot more about whether it works than whether it is totally
new. It would be truly innovative to have software weenies get used to
writing the code just as it was specified and leaving out every extra "hook"
or whatever that wasn't in the spec, hence won't be accounted for in the
doc's.

It would be truly innovative to have it tested systematically with a wide
range of inputs, both random and systematic and to great depth to make sure
that there's no way to make it go down the toilet, especially not by
inadvertent input at the "wrong" time or place. I'd say that at a minimum
it ought to be tested with every possible input of a single character at
times when input is not expected and every combination of 2^32 chacters at
every point at which input is anticipated. The software should behave in an
entirely predictable way and give messages that are totally self
explanatory. Do I really think American programmers will ever take their
work that seriously, . . . No, but they should at least think about it,
don't you think? It could be done automatically, though, couldn't it?
First we should hope that the pro's learn not to write memory leaks, eh?
>
> Although I might be more inclinded to remove redundant calls (that differ
> only in device) but that's a step down the Unix direction.
>
That's a feature that came about when one fellow wrote one version and then,
having become the boss, expected someone else to pick up where he left off,
but not damage any of his now-sacred work.
>
> > > There are also two ways to call MS-DOS functions, one through the
> > > documented interrupt call (INT 21h), the other a call to location
0005h
> > > (that is, for a COM program consisting of a single segment, calling
location
> > > 0005h in the current segment has the same effect of calling INT
21h---for an
> > > EXE program you may not be able to do it since the PSP (the segment
the call
> > > lives in) is in a different segment than the rest of the program
> > > typically)), which is how you call BDOS in CP/M.
> > >
> > Since there is only one segment in CP/M, I guess you've got 'em there.
Of
> > course it really doesn't matter what the location is, does it? I guess
any
> > OS that load a register and then calls a specific location is a copy of
> > CP/M, right?
>
> Not outright. And it's not like MS-DOS used that as the ONLY way to
call
> the operating system---the preferred method was still INT 21h. I suspect
it
> was only put in to help migrate software from CP/M to MS-DOS.
>
Now there's an interesting notion! A programmer actually did something to
help out the struggling programmers who were going to have to live with his
work. How thoughtful! You don't suppose those not-so-glaring similarities
between the two OS' might actually exist because the authors thought it wise
to make the environment familiar, or at least familiar-looking.
> > >
> > > The register usage is different, but that's only to be expected
because of
> > > differences between the 8080 and 8086, but 8080 code could be
mechanically
> > > translated to 8086 since there was a one-to-one relationship between
> > > registers. It wouldn't produce optimal code, but it would produce
code that
> > > would more or less work and these register mappings map pretty well
between
> > > the CP/M and MS-DOS calls.
> >
> > The mapping of one register set into the other is not an accident. Ask
> > Intel about that!
>
> Why bother, I know the register mapping was intentional to help the
> migration of source code (mostly in assembly) from the 8080 to 8086. It
was
> Motorola that took a large gamble at the time in making the 68000
> incompatible with the 6800 line in all respects.
>
> > I'm told that CP/M-86 is considerably more than a
> > translation of CP/M-80. Now you suggest that the roots of MS-DOS are
> > entirely in CP/M? They may have common roots, as they reflect the then
> > conventional wisdom about how one should write a microcomputer operating
> > system. It should be no surprise to anyone that there are some
> > similarities. One doesn't want to ignore what works just because it
wasn't
> > invented in house.
>
> I would say that the roots of MS-DOS 1.x are entirely in CP/M, while
with
> 2.x the influence of other operating systems (notably Unix) start to show
> up. Then again, CP/M wasn't created wholecloth either, it had roots from
> RT-11 (I think that's the OS), which Gary Kildall had experience with.
>
> > After all, Pascal is not a copy of Algol just because it
> > uses mnemonic variable names.
>
> I'm not sure what you mean by that. Yes, Pascal and Algol are in the
same
> family of computer languages but a Pascal source code does not an Algol
> program make.
>
What I meant was that the fact that my wagon has 4 wheels like yours doesn't
make it a copy.
>
> > > Tim Patterson, who wrote the initial version of MS-DOS while at
Seattle
> > > Products, may have had access to CP/M sources since Seattle Products
sold
> > > CP/M systems and they were working on an 8086 based computer in the
late
> > > 70s. Tim probably modeled his QDOS (Quick-n-Dirty Operating System)
closely
> > > after CP/M (some say he may have mechanically translated CP/M since
> > > copyright statements to Digital Research have allegedly been found in
MS-DOS
> > > 1.x but I haven't seen any). Why not? It would have been a quick and
easy
> > > way to get an OS for the 8086 system up and running.
> >
> > I've heard that, too. Does that mean that anyone who writes a program
to do
> > what he's seen another program do is making a copy?
>
> Ask the lawyers or philosophers.
>
> > You're not even sure he
> > actually saw and read the source code. How many programmers do you know
> > who'd simply copy someone else's work in a case like this? Everybody
wants
> > to leave his own mark.
>
> I don't know about then, but now I would suspect that most programmers
> would simply copy without bothering to leave their own mark (in case you
> might not have picked up on it, I don't hold programmers in very high
> reguard and I'm a programmer! Most programmers can't these days, as I'm
> sure Tony would say most electrical engineers today can't either).
>
> > > Microsoft's coming along and obtaining QDOS for $50,000 isn't that
> > > straightforward but that's a story for another time.
> > >
> > Buying something that shortens your burden is kind-of like buying an
> > integrated circuit rather than making the thing yourself starting with a
> > wheelbarrow of sand. The fact that Microsoft knew that IBM had gone to
> > Kildall probably told them what they wanted was sort-f like CP/M.
>
> Like I said, the story of MS-DOS isn't that straightforward. Bill Gates
> even told IBM to check with Digital Research for their OS. It was only
when
> IBM came back saying they were having negotiation difficulties with DR did
> Bill Gates offer them an OS from Microsoft.
>
> Bill Gates knew of QDOS and worked with SCP to licence it from them,
> without telling SCP who their primary customer was. SCP was a bit peeved
> when it learned that Microsoft's customer was IBM.
>
> It wasn't until a few years later did Microsoft buy QDOS outright, after
> SCP had gone bankrupt.
>
Not nice, perhaps, but entirely legal. I won't claim that this behavior is
innovative, however.
>
> > > Apple was working on a version of BASIC for the Macintosh that would
> > > resemble VB today in the late 80s/early 90s. Microsoft got wind of it
and
> > > threatened to cut their license to Microsoft BASIC for the APPLE II
(still
> > > amoney maker at the time) if Apple actually released the product.
Apple
> > > towed the line and what do you know---Microsoft produces this very
> > > innovative product called Visual Basic shortly thereafter, but for
Windows.
> > >
> > ... and now you'd like me to believe that MS knew this and copied it?
> > Frankly, if I'd been in Billy's place, knowing that Apple had considered
it
> > would have scared me off.
>
> This is Bill we're talking about here ... 8-)
>
> -spc (Amature computer historian ... )
>
that's AMATEUR, you HISTORIAN
>
>
WIth few exceptions, this tracks the PBS "revenge of the nerds" account of
these events pretty closely. The thinly veiled truth must be in there
somewhere.
Received on Fri Apr 07 2000 - 21:52:30 BST