[TUHS] Algol68 vs. C at Bell Labs

[Marc Rochkind]

Clem Cole: "IBM allowed the system to be cloned"

I never looked at it that way. To discourage cloning, IBM published and
copyrighted the BIOS source code. Most serious programmers were very
familiar with it, because one had to know details of the BIOS to program
the computer, for many applications (such as ours). That reduced the number
of programmers who could work on a BIOS clone, as such people would have to
be recruited from outside the world of the IBM PC. A few outfits sprang up
to do clean-room BIOS clones, including an outfit called Phoenix, which had
the best. Compaq's internal BIOS was also excellent.

As for the computer hardware, it was just Intel parts along with
off-the-shelf floppy disk controllers and drives and other such stuff. IBM
had built the PC almost entirely from existing parts, and had no exclusive
on any of it.

For the clones, no copyrighted code was used, the programmers had never
seen the code, and the function of the BIOS wasn't copyrightable. So, IBM
really had no way to prevent the clones.

There were a lot of PCs in the early 1980s that weren't clones. They had
8088 or 8086 CPUs, and looked liked PCs, but they weren't identical, so we
had to port our software. Sometimes companies gave us machines, including
AT&T, whose PC was made by Olivetti. I remember many conversations with
computer vendors in which I was just trying to get the memory address and
layout for the screen. They never could even understand the question. DEC,
which had their own weird version of a PC, was the worst.

Within a few years all these went away, and only identical clones existed,
for which we didn't need to develop a special version.

A few people here have said that IBM could have produced a more
sophisticated OS. Actually, I would have been against anything that took up
more resident memory. Initially, I think the most memory IBM would supply
was 384K, and most serious applications needed it all. Multiprogramming or
sophisticated system calls of any sort would have sucked up valuable
memory. I was able to design the EDIX editor to be entirely memory
resident, even with multiple active files, with no floppy swapping at all.

As someone mentioned, we pretty much used MS-DOS only for its file
management. Access to all other facilities was through the BIOS or directly
to the hardware. With such a completely unprotected system, running more
than one application at a time was out of the question.

One might ask why we had such a primitive system with 384K, when UNIX had
been developed over 10 years before on a smaller system. Simple: UNIX had
swapping. With no hard drive, and floppies being inserted and removed,
everything had to be resident in RAM. In addition, as I've mentioned
already, screen speed is what distinguished PC software, ever since Apple
games and Visicalc. Traditional UNIX screen speed was ridiculously slow,
until the workstations came along, but for many times the price of a PC. To
get the screen speed on a PC, the application had to own the hardware. UNIX
insists on standing between the application and the hardware. In PC land
that would be unacceptable.

--Marc

On Thu, Jun 30, 2016 at 2:57 PM, Nemo <cym224 at gmail.com> wrote:

> On 30 June 2016 at 15:21, Diomidis Spinellis <dds at aueb.gr> wrote:
> [...]
> > Two factors might had made the choice of 8088 a more practical one for
> IBM.
> >
> [...]
> > In addition, the 8086 architecture was an extension of the 8080 one,
> which
> > made it easier to make the MS-DOS API compatible with the CP/M one, which
> > was used by many popular programs.  This would simplify their porting.
> (A
> > lot of early IBM PC software was written in assembly language.)
>
> I heard that a lot of the BIOS was a simple-minded translation of
> corresponding 8080-assembler.  I believe that; if you look at the
> horrible assembler, which was actually printed in the IBM Technical
> Manual, you could see that most 8086 extensions were not used.
>
> N.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/e6c206e9/attachment.html>