[TUHS] Algol68 vs. C at Bell Labs

[TUHS] Algol68 vs. C at Bell Labs

[scj]

Steve Bourne tried hard to interest us in A68, and I personally liked some
features of it (especially the automatic type morphing of arguments into
the expected types).  But the documentation was a huge barrier--all the
familiar ideas were given completely new (and unintuitive) names, making
it very difficult to get into.

I may be biased in my view, but I think one fatal mistake that A68 made
was that it had no scheme for porting the language to the plethora of
computers and systems around at that time.  (The Bliss language from CMU
had a similar problem, requiring a bigger computer to compile for the
PDP-11).  Pascal had P-code, and gave C a real run, especially as a
teaching language.  C had PCC.

Nowadays, newer languages like Python just piggyback on C or C++...

[TUHS] Algol68 vs. C at Bell Labs

[Dave Horsfall]

On Wed, 29 Jun 2016, scj at yaccman.com wrote:

> Pascal had P-code, and gave C a real run, especially as a teaching 
> language.

Something I picked up at Uni was that Pascal was never designed for 
production use; instead; you debugged your algorithm in it, then ported it 
to your language of choice.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Algol68 vs. C at Bell Labs

[John Cowan]

scj at yaccman.com scripsit:

> Steve Bourne tried hard to interest us in A68, and I personally liked some
> features of it (especially the automatic type morphing of arguments into
> the expected types).  But the documentation was a huge barrier--all the
> familiar ideas were given completely new (and unintuitive) names, making
> it very difficult to get into.

I heartily agree.  That and the van Wijngaarden grammar were serious
roadblocks to understanding, though such grammars are themselves very
elegant, especially in the form used by the Revised Report.

> I may be biased in my view, but I think one fatal mistake that A68 made
> was that it had no scheme for porting the language to the plethora of
> computers and systems around at that time.  (The Bliss language from CMU
> had a similar problem, requiring a bigger computer to compile for the
> PDP-11).  Pascal had P-code, and gave C a real run, especially as a
> teaching language.  C had PCC.

Indeed.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
That you can cover for the plentiful and often gaping errors, misconstruals
and disinformation in your posts through sheer volume -- that is another
misconception.  --Mike to Peter

[TUHS] Algol68 vs. C at Bell Labs

[arnold]

scj at yaccman.com wrote:

> Nowadays, newer languages like Python just piggyback on C or C++...

Yes and know; GCC has a number of front-ends, in various stage of
production worthiness. Besides C and C++ the Ada front end is full
production quality.  I think Fortran and Java are at lower levels; there
are also D, Go, and Pascal front ends.

There is a trend back towards compiled languages. Of note: D, Go, and Rust.

For whatever it's worth. :-)

Arnold

[TUHS] Algol68 vs. C at Bell Labs

[arnold]

arnold at skeeve.com wrote:

> Yes and know; GCC has a number of front-ends, in various stage of

Not enough sleep. Obviously "yes and no". Sorry.

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4371 bytes --]

Steve - good stuff.   comments below.

On Wed, Jun 29, 2016 at 11:17 AM, <scj at yaccman.com> wrote:

> But the documentation was a huge barrier

​Amen​ - I remember trying to read the report and getting utterly befuddled.



> --all the
> ​ ​
> familiar ideas were given completely new (and unintuitive) names, making
> ​ ​
> it very difficult to get into.
>
​And as importantly, it was not clear to many of us what we were getting
for all that stuff.   Was it sugar or really going to help?​    C, BLISS,
PL/360, BCPL et al, took a much more minimalist view.   Algol68 seems like
it was the "one ring to rule them all" but how could you be sure?



>
> I may be biased in my view, but I think one fatal mistake that A68 made
> was that it had no scheme for porting the language to the plethora of
> computers and systems around at that time.

​I would put this this a little differently.   To me it was not so much
that there was or was not a scheme to move the language, but it was not
economical to try.​   Between your and Dennis's compilers, which were both
"reachable" by many of us, when we needed a language and compiler for these
new microprocessors that were becoming prevalent at the same time, we had
the sources for your compilers and it was "just a matter of a new back
end."



> (The Bliss language from CMU
> ​ ​
> had a similar problem, requiring a bigger computer to compile for the
> ​ ​
> PDP-11).

​While true, I'm not so sure that was the real problem with BLISS.  I
really think it was that CMU sold the language to DEC and compiler sources
were not available to people.   I've always said if DEC had given away the
BLISS compiler and made the sources available in the same manner as C (or
Pascal for that matter), folks like me would have been tempted to use it
write a backend for the 68K (Z8000, 8086 much less the 8-bit micros).​

I also think the size issue could have been (and would have been) fixed if
it was worth it.   But it was not.  The requirement of needing a PDP-10 (or
later Vax) to run was due to the small address space of the PDP-11 and the
amazing things that the BLISS optimizer did.   But you are correct - that
was never done, so it certainly added why BLISS never went very far.

My own experience was simple. At Tektronix, in the late 1970's I was given
a chip that would become the 68K (it was yet to be numbered by Motorola at
that point) and I wanted a HLL for the system we started to make with it
(what would later be called Magnolia).  As a V6 (and later V7) licensee, I
had the sources to the Ritchie compiler.  I knew both BLISS and C (as well
as Algol/Pascal/FTN/PL-1 et,), and I admit in those days still had a
fondness for the former as a CMU grad and Bill Wulf student.   But I did
not have any of the CMU tools (PQCC et al) much less the DEC ones (and you
are correct, I ould get access to the PDP-10, but I had a couple of UNIX
boxes available).  So, I had your tools and they worked well.   Thus,
I wrote a back end for my project for that chip.  It was that simple.   It
was pure economics.




> Pascal had P-code, and gave C a real run, especially as a
> teaching language.

​Right, Pascal had a number of generally available compilers, with P-Code
being the most used.​  It was as economical as C to work.   And a lot of
people used it.  While I liked it as a teaching language, it was useless as
a production language unless you hacked on it and extended it.  And as
importantly for me, it could not be used as a "systems" language as it.  In
fact, at that time Tektronix has at least 6 different but incompatible
flavors of "Tek Pascal." It was language of choice in the product teams
(BTW, our friends and rivals had over 20 flavors of HP BASIC in those days
too).

I picked C because I could and I knew my PDP-11 code would pretty much just
work on this new device.   Admittedly "proof by lack of imagination" reined
here, but I really could not image trying to use Pascal to write an OS.
 I knew I could with BLISS or C.




> Nowadays, newer languages like Python just piggyback on C or C++...

​Hmm... I would say piggyback on the C ecosystem - i.e. GCC (or now LLVM).​

​Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/f8c8ad8f/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Marc Rochkind]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6020 bytes --]

Bill Cheswick: "What a different world it would be if IBM had selected the
M68000 and UCSD Pascal.  Both seemed
to me to better better choices at the time."

Not for those of us trying to write serious software. The IBM PC came out
in August, 1981, and I left Bell Labs to write software for it full time
about 5 months later. At the time, it seemed to me to represent the future,
and that turned out to be a correct guess.

Microsoft Basic is well known as the primary initial language for the PC,
but from day one there was another choice called Microsoft Pascal (we used
the IBM Pascal version). It was a considerable extension over classical
Pascal. It had full-blown string manipulation and pointers. With it, I was
able to implement a text editor called EDIX and an nroff-ripoff called
WORDIX. The compiler was full of bugs, but it was a true compiler, and the
programs were small enough and fast enough to work well on the limited 8088
(I think that was the processor) hardware.

Initially, with no hard drive, I had to switch floppies several times just
to compile one file. Later, I got a 6MB hard drive for about $3000.
Interestingly, that drive could not even hold one (raw) image from my
current digital camera!

We could not have used Microsoft Basic or UCSD Pascal.

Just a few years later, something called Lattice C came along, and we
switched (back) to C, and stayed with it from there on out.

--Marc

On Thu, Jun 30, 2016 at 7:22 AM, Clem Cole <clemc at ccc.com> wrote:

> Steve - good stuff.   comments below.
>
> On Wed, Jun 29, 2016 at 11:17 AM, <scj at yaccman.com> wrote:
>
>> But the documentation was a huge barrier
>
> ​Amen​ - I remember trying to read the report and getting utterly
> befuddled.
>
>
>
>> --all the
>> ​ ​
>> familiar ideas were given completely new (and unintuitive) names, making
>> ​ ​
>> it very difficult to get into.
>>
> ​And as importantly, it was not clear to many of us what we were getting
> for all that stuff.   Was it sugar or really going to help?​    C, BLISS,
> PL/360, BCPL et al, took a much more minimalist view.   Algol68 seems like
> it was the "one ring to rule them all" but how could you be sure?
>
>
>
>>
>> I may be biased in my view, but I think one fatal mistake that A68 made
>> was that it had no scheme for porting the language to the plethora of
>> computers and systems around at that time.
>
> ​I would put this this a little differently.   To me it was not so much
> that there was or was not a scheme to move the language, but it was not
> economical to try.​   Between your and Dennis's compilers, which were both
> "reachable" by many of us, when we needed a language and compiler for
> these new microprocessors that were becoming prevalent at the same time, we
> had the sources for your compilers and it was "just a matter of a new back
> end."
>
>
>
>> (The Bliss language from CMU
>> ​ ​
>> had a similar problem, requiring a bigger computer to compile for the
>> ​ ​
>> PDP-11).
>
> ​While true, I'm not so sure that was the real problem with BLISS.  I
> really think it was that CMU sold the language to DEC and compiler sources
> were not available to people.   I've always said if DEC had given away the
> BLISS compiler and made the sources available in the same manner as C (or
> Pascal for that matter), folks like me would have been tempted to use it
> write a backend for the 68K (Z8000, 8086 much less the 8-bit micros).​
>
> I also think the size issue could have been (and would have been) fixed if
> it was worth it.   But it was not.  The requirement of needing a PDP-10 (or
> later Vax) to run was due to the small address space of the PDP-11 and the
> amazing things that the BLISS optimizer did.   But you are correct - that
> was never done, so it certainly added why BLISS never went very far.
>
> My own experience was simple. At Tektronix, in the late 1970's I was given
> a chip that would become the 68K (it was yet to be numbered by Motorola at
> that point) and I wanted a HLL for the system we started to make with it
> (what would later be called Magnolia).  As a V6 (and later V7) licensee, I
> had the sources to the Ritchie compiler.  I knew both BLISS and C (as well
> as Algol/Pascal/FTN/PL-1 et,), and I admit in those days still had a
> fondness for the former as a CMU grad and Bill Wulf student.   But I did
> not have any of the CMU tools (PQCC et al) much less the DEC ones (and you
> are correct, I ould get access to the PDP-10, but I had a couple of UNIX
> boxes available).  So, I had your tools and they worked well.   Thus,
> I wrote a back end for my project for that chip.  It was that simple.   It
> was pure economics.
>
>
>
>
>> Pascal had P-code, and gave C a real run, especially as a
>> teaching language.
>
> ​Right, Pascal had a number of generally available compilers, with P-Code
> being the most used.​  It was as economical as C to work.   And a lot of
> people used it.  While I liked it as a teaching language, it was useless as
> a production language unless you hacked on it and extended it.  And as
> importantly for me, it could not be used as a "systems" language as it.  In
> fact, at that time Tektronix has at least 6 different but incompatible
> flavors of "Tek Pascal." It was language of choice in the product teams
> (BTW, our friends and rivals had over 20 flavors of HP BASIC in those days
> too).
>
> I picked C because I could and I knew my PDP-11 code would pretty much
> just work on this new device.   Admittedly "proof by lack of imagination"
> reined here, but I really could not image trying to use Pascal to write an
> OS.    I knew I could with BLISS or C.
>
>
>
>
>> Nowadays, newer languages like Python just piggyback on C or C++...
>
> ​Hmm... I would say piggyback on the C ecosystem - i.e. GCC (or now LLVM).​
>
> ​Clem​
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/fa076930/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[William Cheswick]

I understand there were a number of problems that went the other way.  Motorola dropped the ball, software
was buggy, and IBM needed an immediate answer.

On the other hand, there was
no excuse for a Pascal compiler to be either large, buggy, or slow, even before Turbo Pascal.


> On 30Jun 2016, at 10:05 AM, Marc Rochkind <rochkind at basepath.com> wrote:
> 
> Not for those of us trying to write serious software. The IBM PC came out in August, 1981, and I left Bell Labs to write software for it full time about 5 months later. At the time, it seemed to me to represent the future, and that turned out to be a correct guess.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/f2d058b2/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Ronald Natalie]

> 
> On the other hand, there was
> no excuse for a Pascal compiler to be either large, buggy, or slow, even before Turbo Pascal.
> 
I remember the Pascal computer on my Apple II used to have to use some of the video memory while it was running.

[TUHS] Algol68 vs. C at Bell Labs

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

William Cheswick <ches at cheswick.com> wrote:

> On the other hand, there was
> no excuse for a Pascal compiler to be either large, buggy, or slow, even before Turbo Pascal.

Large?

The original Wirth pascal compiler source was 1800 lines of pascal code.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[TUHS] Algol68 vs. C at Bell Labs

[Ori Idan]

On Thu, Jun 30, 2016 at 5:57 PM, Joerg Schilling <schily at schily.net> wrote:

> William Cheswick <ches at cheswick.com> wrote:
>
> > On the other hand, there was
> > no excuse for a Pascal compiler to be either large, buggy, or slow, even
> before Turbo Pascal.
>
> Large?
>
> The original Wirth pascal compiler source was 1800 lines of pascal code.
>

Pascal compiler written in Pascal? how can I compile the compiler it I
don't yet have a pascal compiler? :-)

Ori Idan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/ec8dbba7/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Dave Horsfall]

On Thu, 30 Jun 2016, Ori Idan wrote:

> Pascal compiler written in Pascal? how can I compile the compiler it I 
> don't yet have a pascal compiler? :-)

I've always said that the ultimate test of a compiler was whether it could 
compile itself.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Algol68 vs. C at Bell Labs

[Jesus Cea]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On 30/06/16 17:07, Ori Idan wrote:
> Pascal compiler written in Pascal? how can I compile the compiler it I
> don't yet have a pascal compiler? :-)

That is standard procedure:

https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29

-- 
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160701/ac98b9bc/attachment.sig>

[TUHS] Algol68 vs. C at Bell Labs

[Dan Cross]

On Jun 30, 2016 10:10 AM, "Marc Rochkind" <rochkind at basepath.com> wrote:

> Bill Cheswick: "What a different world it would be if IBM had selected
> the M68000 and UCSD Pascal.  Both seemed
> to me to better better choices at the time."
>
> Not for those of us trying to write serious software. The IBM PC came out
> in August, 1981, and I left Bell Labs to write software for it full time
> about 5 months later. At the time, it seemed to me to represent the future,
> and that turned out to be a correct guess.
>
> Microsoft Basic is well known as the primary initial language for the PC,
> but from day one there was another choice called Microsoft Pascal (we used
> the IBM Pascal version). It was a considerable extension over classical
> Pascal. It had full-blown string manipulation and pointers. With it, I was
> able to implement a text editor called EDIX and an nroff-ripoff called
> WORDIX. The compiler was full of bugs, but it was a true compiler, and the
> programs were small enough and fast enough to work well on the limited 8088
> (I think that was the processor) hardware.
>

I don't know about UCSD Pascal versus MS-DOS, but I think you yourself just
alluded to the processor distinction that Ches was referring to. Of course
it's only of historical interest now, but from a technology standpoint
MC68000 vs Intel 8088 seems like a no-brainer: the 68k is the superior
chip. From a business perspective, I guess it was a very different matter,
but that's not my area and the ship has long sailed over the horizon.
Still, it's fun to speculate and I can't help but think that a 68k-based
IBM PC would have been a nicer machine.

Initially, with no hard drive, I had to switch floppies several times just
> to compile one file. Later, I got a 6MB hard drive for about $3000.
> Interestingly, that drive could not even hold one (raw) image from my
> current digital camera!
>
> We could not have used Microsoft Basic or UCSD Pascal.
>
> Just a few years later, something called Lattice C came along, and we
> switched (back) to C, and stayed with it from there on out.
>

Something I never understood about the IBM PC: even the 8088 machine was
fairly beefy compared to e.g. a PDP-11/20. The 6th Edition Unix kernel was
objectively pretty small and understandable; mini-Unix showed that that
sort of software could be used on a machine without an MMU. I've never
understood why IBM didn't just write a real OS in a high-level language
instead of saddling the world with MS-DOS. Perhaps it's naive of me, but
even if they didn't use Unix directly, it was an existence proof that such
a thing was possible. I suppose, again, it was less a technical issue and
more a business issue, or perhaps I'm underestimating the amount of work or
missing some of the technical complexities.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/edfb7e55/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Larry McVoy]

On Thu, Jun 30, 2016 at 11:32:08AM -0400, Dan Cross wrote:
> MC68000 vs Intel 8088 seems like a no-brainer: the 68k is the superior
> chip. From a business perspective, I guess it was a very different matter,
> but that's not my area and the ship has long sailed over the horizon.
> Still, it's fun to speculate and I can't help but think that a 68k-based
> IBM PC would have been a nicer machine.

+1

> Something I never understood about the IBM PC: even the 8088 machine was
> fairly beefy compared to e.g. a PDP-11/20. The 6th Edition Unix kernel was
> objectively pretty small and understandable; mini-Unix showed that that
> sort of software could be used on a machine without an MMU. I've never
> understood why IBM didn't just write a real OS in a high-level language
> instead of saddling the world with MS-DOS. Perhaps it's naive of me, but
> even if they didn't use Unix directly, it was an existence proof that such
> a thing was possible. I suppose, again, it was less a technical issue and
> more a business issue, or perhaps I'm underestimating the amount of work or
> missing some of the technical complexities.

I wonder if they just didn't know.  Unix was Bell Labs and Universities for
the most part.  Was the timing such that they may not have been aware of 
Unix?  Or maybe they knew about Unix but thought it was for the vax?

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3576 bytes --]

On Thu, Jun 30, 2016 at 11:49 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Jun 30, 2016 at 11:32:08AM -0400, Dan Cross wrote:
> > MC68000 vs Intel 8088 seems like a no-brainer: the 68k is the superior
> > chip. From a business perspective, I guess it was a very different
> matter,
>
​Yup - you take what you can get.  And if Moto is not doing to sell it you
when you are designing a new system.​




> > but that's not my area and the ship has long sailed over the horizon.
> > Still, it's fun to speculate and I can't help but think that a 68k-based
> > IBM PC would have been a nicer machine.
>
> +1
>
​+1  And  I suspect so many fewer problems would have ensued.   At least
linear addressing would have been de rigueur from day 1;-)
​

>
> > Something I never understood about the IBM PC: even the 8088 machine was
> > fairly beefy compared to e.g. a PDP-11/20. The 6th Edition Unix kernel
> was
> > objectively pretty small and understandable; mini-Unix showed that that
> > sort of software could be used on a machine without an MMU. I've never
> > understood why IBM didn't just write a real OS in a high-level language
> > instead of saddling the world with MS-DOS. Perhaps it's naive of me, but
> > even if they didn't use Unix directly, it was an existence proof that
> such
> > a thing was possible. I suppose, again, it was less a technical issue and
> > more a business issue, or perhaps I'm underestimating the amount of work
> or
> > missing some of the technical complexities.
>
> I wonder if they just didn't know.

​Possible -- ignorance of that team would have been high, certainly at the
managerial layers.   You might ask Guy Sotomayer who showed up in Boca soon
after the release if not before it.   Guy certainly knew UNIX (he was one
of my lab partners at CMU​) and I'm sure a number of his peers did also.




> Unix was Bell Labs and Universities for
> ​ ​
> the most part.

​Mumble, IBM was selling to universities and has a strong on-site presence
at MIT (that's were VM came from).   Boca was doing stuff with 8085s and
this was "entry systems" so I think the field of view was a lot more
shallow.​   But parts of IBM knew about UNIX and TOPS-10.   One of Guy and
my other lab partners was Chris Pathe', who graduated from CMU to work for
IBM, but programming DEC systems for them.   They hired him because he knew
TOPS and UNIX, *etc.*



> Was the timing such that they may not have been aware of
> Unix?  Or maybe they knew about Unix but thought it was for the vax?

Stuff I have read said that IBM wanted to compete originally with S-100
type systems with this new system.   Hence the famous desire for CP/M​.
They always were primarily buying the SW from firms that had built SW for
microprocessors.  And, if I understand the history pieces that have been
published, the project was financed by large systems, that wanted to system
to run VisiCalc, which was a hit in financial circles.   But large systems
team were not doing much the SW themselves for these boxes.  It >>seems<<
like IBM was thinking about SW in terms of very large machines so even
PDP-11's were small in those days.  That said their marketing folks for the
PC, put the focus on 16 bits was because they wanted to be "better" than
the 8-bit 8080/8085/Z80 that was the S-100 standard or the 6502 in the
Apple II.   Hence, Moto pushing an 8-bit chip was rejected.


​Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/fa5ba429/attachment.html>

[TUHS] OS for IBM PC (was: Algol68 vs. C at Bell Labs)

[Greg 'groggy' Lehey]

On Thursday, 30 June 2016 at  8:49:26 -0700, Larry McVoy wrote:
> On Thu, Jun 30, 2016 at 11:32:08AM -0400, Dan Cross wrote:
>> Something I never understood about the IBM PC: even the 8088 machine was
>> fairly beefy compared to e.g. a PDP-11/20. The 6th Edition Unix kernel was
>> objectively pretty small and understandable; mini-Unix showed that that
>> sort of software could be used on a machine without an MMU. I've never
>> understood why IBM didn't just write a real OS in a high-level language
>> instead of saddling the world with MS-DOS. Perhaps it's naive of me, but
>> even if they didn't use Unix directly, it was an existence proof that such
>> a thing was possible. I suppose, again, it was less a technical issue and
>> more a business issue, or perhaps I'm underestimating the amount of work or
>> missing some of the technical complexities.
>
> I wonder if they just didn't know.  Unix was Bell Labs and
> Universities for the most part.  Was the timing such that they may
> not have been aware of Unix?  Or maybe they knew about Unix but
> thought it was for the vax?

Not directly related, but I don't know which other message in this
subthread is more relevant:

Don't forget the constraints on the PC design.  The IBM model number
was 5150: it was a last-ditch attempt to salvage the not very
successful 5100 series.  To do so they outsourced things that IBM
would normally have developed in-house.  And that meant taking
existing products, not creating new ones.  The success of the PC
caught IBM by surprise, like the 704 30 years earlier.

At the time IBM talked to Microsoft, Microsoft's OS plans were clear:
XENIX.  See the August 1980 (I think) issue of Byte, where there's a
long story about why XENIX is the correct choice of operating system.
You can be sure that Microsoft tried to sell that first.  But instead
they had to go out and buy QDOS from Seattle Computer Products.

And why?  Yes, the 8088 was a reasonably fast processor, so fast that
they could slow it down a little so that they could use the same
crystal to create the clock both for the CPU and the USART.  But the
base system had only 16 kB memory, only a little more than half the
size of the 6th Edition kernel.  Even without the issue of disks
(which could potentially have been worked around) it really wasn't big
enough for a multiprogramming OS.

[TUHS] Algol68 vs. C at Bell Labs

[John Cowan]

Dan Cross scripsit:

> I've never understood why IBM didn't just write a real OS in a
> high-level language instead of saddling the world with MS-DOS.

I think because to IBM "a real OS" meant MVS.  The difference between
Unix and MS-DOS simply wasn't visible to them.  

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Don't be so humble.  You're not that great.
        --Golda Meir

[TUHS] Algol68 vs. C at Bell Labs

[Marc Rochkind]

Dan Cross: "... even if they didn't use Unix directly, it was an existence
proof that such a thing was possible".

Indeed it was. IBM contracted with Interactive Systems (Heinz Lycklama's
company, in Santa Monica) to produce PC/IX, which was complete System 3 for
the IBM PC. 8088, 4.77MHz, and 512K of RAM (if I'm remembering the numbers
correctly). It was my primary development system for the first edition of
Advanced UNIX Programming.

As for why "IBM" didn't do something other than MS-DOS originally: It
depends what you mean by "IBM". The PC was not originally strategic,
although it might have become that way after a few years. It was just a
small group in Boca Raton (as I recall) that whipped it out pretty quickly.
MS-DOS was a good choice within the class of what then were known as
personal computer operating systems (CP/M being the leader for 8080/Z80
Intel systems).

I don't think PC/IX would have run on a floppy-only system. And, if it
would, it would have been a demonstration only--entirely impractical. IBM
didn't provide a PC with a hard drive until later, and that's when PC/IX
came along.

Don't forget that the IBM PC completely dominated office use where personal
computers were needed. A runaway success. That makes me think that the
technical solutions were correct for what the project was supposed to
achieve.

When I tried to write responsive software for UNIX and UNIX-like OSes
running on PCs, I could never achieve good results because the display
support was inadequate. Typically, you treated the display like a terminal
(escape sequences). MS-DOS allowed me to write to display memory directly,
which what was made PC software so responsive.

To say it another way, UNIX on a PC was always just a port. No
consideration was given to providing support for the way PCs were actually
used. That didn't happen until Xerox PARC started to produce PCs (at a much
higher cost, of course). The first decent "PC" was the Macintosh SE. The
earlier Macs were dogs.

--Marc



On Thu, Jun 30, 2016 at 11:07 AM, John Cowan <cowan at mercury.ccil.org> wrote:

> Dan Cross scripsit:
>
> > I've never understood why IBM didn't just write a real OS in a
> > high-level language instead of saddling the world with MS-DOS.
>
> I think because to IBM "a real OS" meant MVS.  The difference between
> Unix and MS-DOS simply wasn't visible to them.
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> Don't be so humble.  You're not that great.
>         --Golda Meir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/cad6cee3/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Dan Cross]

On Thu, Jun 30, 2016 at 1:57 PM, Marc Rochkind <rochkind at basepath.com>
wrote:

> Dan Cross: "... even if they didn't use Unix directly, it was an existence
> proof that such a thing was possible".
>
> Indeed it was. IBM contracted with Interactive Systems (Heinz Lycklama's
> company, in Santa Monica) to produce PC/IX, which was complete System 3 for
> the IBM PC. 8088, 4.77MHz, and 512K of RAM (if I'm remembering the numbers
> correctly). It was my primary development system for the first edition of
> Advanced UNIX Programming.
>
> As for why "IBM" didn't do something other than MS-DOS originally: It
> depends what you mean by "IBM". The PC was not originally strategic,
> although it might have become that way after a few years. It was just a
> small group in Boca Raton (as I recall) that whipped it out pretty quickly.
> MS-DOS was a good choice within the class of what then were known as
> personal computer operating systems (CP/M being the leader for 8080/Z80
> Intel systems).
>
> I don't think PC/IX would have run on a floppy-only system. And, if it
> would, it would have been a demonstration only--entirely impractical. IBM
> didn't provide a PC with a hard drive until later, and that's when PC/IX
> came along.
>
> Don't forget that the IBM PC completely dominated office use where
> personal computers were needed. A runaway success. That makes me think that
> the technical solutions were correct for what the project was supposed to
> achieve.
>
> When I tried to write responsive software for UNIX and UNIX-like OSes
> running on PCs, I could never achieve good results because the display
> support was inadequate. Typically, you treated the display like a terminal
> (escape sequences). MS-DOS allowed me to write to display memory directly,
> which what was made PC software so responsive.
>
> To say it another way, UNIX on a PC was always just a port. No
> consideration was given to providing support for the way PCs were actually
> used. That didn't happen until Xerox PARC started to produce PCs (at a much
> higher cost, of course). The first decent "PC" was the Macintosh SE. The
> earlier Macs were dogs.
>

Sorry, I don't think I was being clear in my earlier post. I get that IBM
(for the definition that is the group that built the PC) did not ship a
Unix port and frankly probably wouldn't have. But what irks me is that they
didn't produce an ersatz operating system that could support Unix-like
functionality: for example, support multiple processes, have a real
system-call interface, etc. In other words, why didn't they have a more
capable kernel than MS-DOS? Surely a motivated team could have produced a
floppy-only system capable of running multiple processes, etc. It wouldn't
be Unix, it wouldn't even necessarily be a clone of Unix, but it could have
been something better than MS-DOS.

My impression was that DOS programmers had to jump through a lot of hoops
due to the anemia of the "INT 21h" services, the memory model of the
8088/8086, and lack of a system-standard programming library: I suspect a
lot of them ended up using DOS as little more than a filesystem. Consider
the display issue you mention: as I understand it, programmers could
interact with the display adapter by simply reading and writing to
well-known addresses (did this require special IO instructions? I don't
believe so). Suppose instead that the OS provided a "system call" to "map"
the display memory into one's process and return a small structure
describing it (e.g., base pointer, rows, columns, a bitmap of capabilities
[color and so on]), or -1 on failure. If the mapping were successful, the
programmer could indirect through this pointer and treat the display as one
would in DOS (perhaps with a library to facilitate application
development). On the 8088 that wouldn't be protected, of course, so it
could be bypassed but the 80286 came along fairly shortly after and had an
on-chip MMU with protected mode. Again, it doesn't have to be Unix, but DOS
didn't really help the programmer a lot here as far as I can tell.

I'm not sure I would assert that their success was due to good technical
decisions; this was the era where IBM dominated business and as the saying
went, "no one ever got fired for buying IBM." The IBM brand added de facto
legitimacy to the personal computer in the workplace at a critical time
when it was just starting to make inroads into business: surely their
success had a lot more to do with that than choosing to use the 8088 and
DOS? The VHS vs. Betamax argument may apply here.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/a0d66b45/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]

On Thu, Jun 30, 2016 at 2:31 PM, Dan Cross <crossd at gmail.com> wrote:


> ​...​
> why didn't they have a more capable kernel than MS-DOS?
>
​I don't think they cared. or felt it was needed at the time (I disagreed
then and still do).




> Surely a motivated team could have produced a floppy-only system capable
> of running multiple processes, etc. It wouldn't be Unix, it wouldn't even
> necessarily be a clone of Unix, but it could have been something better
> than MS-DOS.
>
​As Marc pointed out.  The PC was fabulously successful for what it was
designed to be.  They wanted something the run VisiCalc and later a word
processor for corporate America.   We are programmers saw it >>could<< have
been more capable, but they did not really care.   The system way, way out
did what it was planned.   So it's hard to tell folks that did something
bad.

​... ​
> I'm not sure I would assert that their success was due to good technical
> decisions;
>
​exactly.​



> ​...
>  The IBM brand added de facto legitimacy to the personal computer in the
> workplace at a critical time when it was just starting to make inroads into
> business: surely their success had a lot more to do with that than choosing
> to use the 8088 and DOS?
>
​Indeed.​

Although I think a side story is that you did not mention is that IBM
allowed the system to be cloned.  Remember at this same time, Apple out
Franklin computer out of business for cloning the Apple II.    Because the
PC became a standard of sort, because their were choices in getting lower
cost systems, not just buying from IBM.   That ended top cementing it,




> The VHS vs. Betamax argument may apply here.
>
​Maybe - I think of it in terms of economics.​     PCs and DOS
"won" because they were cheaper than any other solution to the a similar
task and it was good enough,   Like VHS/Betamax it was good enough for
many, many people - so economics drove the standard.  But also at the time,
Apple, who had a better product and actually was more polished than MS-DOS
was, was >>perceived<< as being for home use and DOS for business.   IBM
and MSFT and Intel did a great job of convincing people of that idea.   Add
to it that it was cheaper, it was a hard order to get businesses to
consider Macs.

Which is different from Betamax....   business (TV stations/professionals
et al) picked the "better" system.    But they did not here, they picked
the cheap one no matter what.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/747706b7/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3311 bytes --]

On Thu, Jun 30, 2016 at 3:21 PM, Clem Cole <clemc at ccc.com> wrote:
>
> On Thu, Jun 30, 2016 at 2:31 PM, Dan Cross <crossd at gmail.com> wrote:
>>
>> ​...​
>> why didn't they have a more capable kernel than MS-DOS?
>>
> ​I don't think they cared. or felt it was needed at the time (I disagreed
> then and still do).
>

Yeah...I guess you are right.

Surely a motivated team could have produced a floppy-only system capable of
>> running multiple processes, etc. It wouldn't be Unix, it wouldn't even
>> necessarily be a clone of Unix, but it could have been something better
>> than MS-DOS.
>>
> ​As Marc pointed out.  The PC was fabulously successful for what it was
> designed to be.  They wanted something the run VisiCalc and later a word
> processor for corporate America.   We are programmers saw it >>could<< have
> been more capable, but they did not really care.   The system way, way
> out did what it was planned.   So it's hard to tell folks that did
> something bad.
>
> ​... ​
>> I'm not sure I would assert that their success was due to good technical
>> decisions;
>>
> ​exactly.​
>
>
>
>> ​...
>>  The IBM brand added de facto legitimacy to the personal computer in the
>> workplace at a critical time when it was just starting to make inroads into
>> business: surely their success had a lot more to do with that than choosing
>> to use the 8088 and DOS?
>>
> ​Indeed.​
>
> Although I think a side story is that you did not mention is that IBM
> allowed the system to be cloned.  Remember at this same time, Apple out
> Franklin computer out of business for cloning the Apple II.    Because the
> PC became a standard of sort, because their were choices in getting lower
> cost systems, not just buying from IBM.   That ended top cementing it,
>

That's an excellent point.

The VHS vs. Betamax argument may apply here.
>>
> ​Maybe - I think of it in terms of economics.​     PCs and DOS
> "won" because they were cheaper than any other solution to the a similar
> task and it was good enough,
>

I suspect that, at the end of the day, this is the real reason for the
success of the PC. It's easy, as an engineer, to second-guess it and ask
why it couldn't have been "more" than it was, but I suspect a business
person would look at me funny. From a business perspective, it was wildly
successful (until the clone market undercut IBM so much they got out of the
PC business altogether). In economics vs technology, economics almost
always wins.

        - Dan C.


Like VHS/Betamax it was good enough for many, many people - so economics
> drove the standard.  But also at the time, Apple, who had a better product
> and actually was more polished than MS-DOS was, was >>perceived<< as being
> for home use and DOS for business.   IBM and MSFT and Intel did a great job
> of convincing people of that idea.   Add to it that it was cheaper, it was
> a hard order to get businesses to consider Macs.
>
> Which is different from Betamax....   business (TV stations/professionals
> et al) picked the "better" system.    But they did not here, they picked
> the cheap one no matter what.
>
> Clem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/3ed60f2b/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On Thu, Jun 30, 2016 at 3:51 PM, Dan Cross <crossd at gmail.com> wrote:

> In economics vs technology, economics almost always wins.

​Amen - although I would probably have said it as:    s/almost//
Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/12a2e1d9/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On Thu, Jun 30, 2016 at 3:55 PM, Clem Cole <clemc at ccc.com> wrote:
>
> On Thu, Jun 30, 2016 at 3:51 PM, Dan Cross <crossd at gmail.com> wrote:
>
>> In economics vs technology, economics almost always wins.
>
> ​Amen - although I would probably have said it as:    s/almost//
>

That was my escape hatch for the rare but fortuitous moments where the
stars align and the technologically superior solution matches the
economics. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/8bdb2209/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Steve Nickolas]

On Thu, 30 Jun 2016, John Cowan wrote:

> Dan Cross scripsit:
>
>> I've never understood why IBM didn't just write a real OS in a
>> high-level language instead of saddling the world with MS-DOS.
>
> I think because to IBM "a real OS" meant MVS.  The difference between
> Unix and MS-DOS simply wasn't visible to them.

And perhaps even less so when MS-DOS picked up a few of Xenix's features 
for 2.0 (mainly file i/o with Unix-like semantics, but FIND was a 
stripped-down version of "fgrep", and several of the new commands in 2.0 
were certainly derived from Unix...or even BSD), although to anyone who 
actually knew anything, that's about where the similarity ended.

-uso.

[TUHS] Algol68 vs. C at Bell Labs

[Diomidis Spinellis]

On 30/06/2016 18:32, Dan Cross wrote:
> Of
> course it's only of historical interest now, but from a technology
> standpoint MC68000 vs Intel 8088 seems like a no-brainer: the 68k is the
> superior chip.

Two factors might had made the choice of 8088 a more practical one for IBM.

First, the 8088 was a 16-bit CPU with an 8-bit data bus in a cheap 
40-pin package.  This halved the number DRAM chips required and allowed 
the IBM PC to be easily designed along existing easily-available 8-bit 
peripherals.  In contrast the 68000 had a 16-bit data bus in a more 
expensive 64-pin package.  Remember that in the 1980s glue logic was 
implemented through simple TTL chips, so adopting the 68000 might have 
doubled the number of chips on the motherboard.

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.)  The MS-DOS 1.0 interrupts (system calls) even used the same 
numbers and structures (file control blocks - FCBs) as those used by 
CP/M.  MS-DOS 2.0 added file paths and other Unix-influenced abstractions.

[TUHS] Algol68 vs. C at Bell Labs

[Dan Cross]

On Thu, Jun 30, 2016 at 3:21 PM, Diomidis Spinellis <dds at aueb.gr> wrote:

> On 30/06/2016 18:32, Dan Cross wrote:
>
>> Of
>> course it's only of historical interest now, but from a technology
>> standpoint MC68000 vs Intel 8088 seems like a no-brainer: the 68k is the
>> superior chip.
>>
>
> Two factors might had made the choice of 8088 a more practical one for IBM.
>
> First, the 8088 was a 16-bit CPU with an 8-bit data bus in a cheap 40-pin
> package.  This halved the number DRAM chips required and allowed the IBM PC
> to be easily designed along existing easily-available 8-bit peripherals.
> In contrast the 68000 had a 16-bit data bus in a more expensive 64-pin
> package.  Remember that in the 1980s glue logic was implemented through
> simple TTL chips, so adopting the 68000 might have doubled the number of
> chips on the motherboard.
>

It sounds an awful lot like Motorola was actively trying to steer IBM away
from the 68k, but that the 68k was what they really wanted. If that was the
case, presumably they could get the glue logic to an acceptable level. I've
looked at some 68k based board designs and it rarely seems that bad for
small systems; Clements's book has a really nice design for a 68030-based
system, even, that looks like it could be done on a fairly small board.

I wanted to write back and say that the 68008 in the 48-ing DIP package
would address these concerns: 20bit address bus and an 8-bit data bus, but
that doesn't appear to have been available until 1982.

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.)  The MS-DOS
> 1.0 interrupts (system calls) even used the same numbers and structures
> (file control blocks - FCBs) as those used by CP/M.  MS-DOS 2.0 added file
> paths and other Unix-influenced abstractions.
>

That's a fair point. But if they were willing to look at UCSD Pascal,
presumably foregoing CP/M compatibility, why not the Unix syscall interface
as well?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/75af1c55/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Thu, Jun 30, 2016 at 3:43 PM, Dan Cross <crossd at gmail.com> wrote:

> I wanted to write back and say that the 68008 in the 48-ing DIP package
> would address these concerns: 20bit address bus and an 8-bit data bus, but
> that doesn't appear to have been available until 1982.

​When the pick of the 8086/8088 was made, the 68000 did not official exist
either.​  As I understand it, >>I believe<< that the 68008 is just an 68000
die, that is bonded differently.  All the logic is in both chips.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/e21850a1/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]

On Thu, Jun 30, 2016 at 3:21 PM, Diomidis Spinellis <dds at aueb.gr> wrote:

> First, the 8088 was a 16-bit CPU with an 8-bit data bus in a cheap 40-pin
> package.  This halved the number DRAM chips required and allowed the IBM PC
> to be easily designed along existing easily-available 8-bit peripherals.
> In contrast the 68000 had a 16-bit data bus in a more expensive 64-pin
> package.  Remember that in the 1980s glue logic was implemented through
> simple TTL chips, so adopting the 68000 might have doubled the number of
> chips on the motherboard.
>
hrrmpt...​Moto had the 68008 which was an 8 bit bus, smaller # of pins,
plus all of the 68K chips could directly talk the 6800 line of peripheral
chips (I even have an old Moto app note right here telling you how).  In
fact IBM, used a number of 6800 chips in the PC for things like the display
controller.

Also remember in those days IBM and Moto were very, very tight.  MECL
-- Motorola Emitter Coupled Logic was design by Moto for IBM for the 370
family.  TTL or as it was called at IBM - VTL (Vendor Transistor Logic),
was less favored.

That said, what would become the 68000 was TTL levels.   That was because
the prototyped it in TTL (and wrote the microcode on the TTL system).



> In addition, the 8086 architecture was an extension of the 8080 one,
>
​Yes and no.​  Yes the 4004's HL register pair still lives on.  But the
8080/8085 instruction set was different from the 8086.




> 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.)
>
​Yes there were tools to help move assembler code but it still had to be
hand tuned,  Even the PL/M tools were specific to 8080 and 8086.​

But I don't know of much code that took the CP/M to MS-DOS conversion path.




> The MS-DOS 1.0 interrupts (system calls) even used the same numbers and
> structures (file control blocks - FCBs) as those used by CP/M.
>
​Yes, DOS-86 was attempt to rewrite CP/M for the 8086 by Seattle computer
products.  And CP/M was attempt by Digital Research to rewrite RT-11.
There are a lot of common structures, I/O calls and even command names.
 But that is more of the "baby duck syndrome" - it was what the
implementors knew and were used too.​

As other have suggested, it is sad that the model was not UNIX.   The BDS
guys wrote a UNIX-like system for the S-100 machines.   I remember it being
shown to Dennis at a USENIX in the early 1980s and he stating how much
it reminded him of early UNIX.  So yes, the key is that if people had had
other models AND it had made economic sense, the world might have been
different.

But RT-11, ney: CP/M , ney DOS-86, ney PC-DOS, ney MS-DOS >>was<< good
enough as Marc pointed out.   IBM and the Microsoft were fabulously
successful with what they build, even if it was not technically as good as
what was possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/0e0c998f/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Nemo]

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.

[TUHS] Algol68 vs. C at Bell Labs

[Random832]

On Thu, Jun 30, 2016, at 16:57, Nemo wrote:
> 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.

Well, a new system means there are no expert programmers for it, who
have learned all the tricks and how it all fits together. You see
something similar in environments like console video games, with a
progression of higher-performance games within each console generation
as programmers learn to wring more out of the same hardware.

[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>

[TUHS] Algol68 vs. C at Bell Labs

[Random832]

On Thu, Jun 30, 2016, at 19:16, Marc Rochkind wrote:
> ...and the function of the BIOS wasn't copyrightable.

Well, that's apparently not actually settled law, judging by the fact
that Oracle v. Google wasn't laughed out of court nearly thirty years
later.

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5596 bytes --]

Marc,

I mostly agree but you have a little history out of order.  Apple and
Franklin really are important here.  More inline...

On Thu, Jun 30, 2016 at 7:16 PM, Marc Rochkind <rochkind at basepath.com>
wrote:

> 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.
>
​Hang on that it was not quite that simple.   In fact IBM did publish
everything because that was what all the PC folks did at the time.   As did
IBM themselves in their mainframes.   Remember when the PC was originally
developed, Judge Green has not yet left IBM from its bondage.​   So IBM was
very careful in those days to follow industry norms.   The PC folks (like
Apple, Altair, Cromemco et al) published the schematics and the ROM
listings.  The OS's and higher level tools were closed but the rest tended
to be generally available so IBM followed suit.





> ​....​
>  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.
>
​This post the Franklin Computer case.​  Clones of Apple II sprung up, with
CPU motherboards coming from Taiwan.   Hey I made an Apple II clone, as
well as an Xerox 820 clone in those days myself (I may still have the
later).

Franklin Computer of Philadelphia started to sell their Apple II to run
Visacalc - which was the "killer app" of the day (note a theme here).  Jobs
did not like it and took them to court.  I actually knew the main attorney
for Franklin at the time (one of the few big cases he even lost).   Apple
won because it was the contents of the ROM (bit for bit) that was found to
be identical.   The question became could you "copyright" the bits. [There
is a whole side discussion about what the memory chip guys of that day did
to try to keep people from copying them BTW].

Anyway, once that became case law, the concept of a "clean room" was
created.  As you say, Phoenix did a remarkable job.   BTW:  in an
interested side note, years later, IBM sold Phoenix its BIOS and started to
use theirs when the Phoenix BIOS became the gold standard.



>
> As for the computer hardware, it was just Intel parts
>
​Motorola, WD, and TI parts originally.​




> 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.
>
​If they had not published the original material, I suspect it would have
been far, far harder and less attractive.   But also remember, clone in the
IBM land was already around.  Amdahl was selling like hot cakes.  IBM had
learned that with the clone market, they sold more of their own product.
It was an interesting business view.   The pie was getting bigger faster,
so they got a larger amount of pie, even though the percentage of the pie
got smaller.​  So IBM made more money.

This was a lesson a lot of companies, particularly computer firms, never
quite understood.   Having a weak, buy alive competitor is better than no
competition.




>
>
> There were a lot of PCs in the early 1980s that weren't clones.
>
​Absolutely.​  But if the OS has been reasonable and had be able to hide
the differences (and you not be able to go directly to HW addresses etc..)
this would have been less of an issue.




> ​...
> DEC, which had their own weird version of a PC, was the worst.
>
​No doubt.​



> 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.
>
​Truth is folks built systems that swapped to floppies (and cassette tape
et al) in those days.  Originally Magix was going to be in that same camp
when it was a "G-job" by Roger and myself.  When our boss funded its the
first thing we did was add a 10M disk.​




> ​... ​
> To get the screen speed on a PC, the application had to own the hardware.
>
​That was a deficiency of the PC HW design.   Other systems, such as the
Magnolia and later Apollo/Masscomp/Sun, showed you could have fine speed
with out having to do that.  Also in "PC land" consider when the '20 Mac
came out and Apple started to get religion (as did NeXT shortly there
after).

You could do it, but the original PC designs were sloppy and did not care
-- the feeling was that extra HW (and SW to support) was unnecessary.   In
many ways, the original PC guys were right given how far and how long those
systems lived.   But it was painful for the SW building as you pointed out.
   You should not have had to do such "unnatural" or "unsafe" acts.




> UNIX insists on standing between the application and the hardware.
>
​As it should ;-) ​It required  good HW under the covers and then UNIX
drivers that did the the right things.  In the same time frame as the PC
was developed it was definitely possible and would not have cost more.​




> In PC land that would be unacceptable.
>
​Only because the HW sucked and the OS did not have the right types of
structures to make it work.​

Seriously, Marc I get it and you are better man for dealing with the craziness
of the day.  Many of the rest of us would not at the time, and until we got
"real HW" did not mess that much with it.  Then again, I did not care to
run a VisaCalc or a Word Perfect :-)

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/9cfcde67/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Marc Rochkind]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5998 bytes --]

thanks for these comments... lots of interesting stuff

On Thursday, June 30, 2016, Clem Cole <clemc at ccc.com> wrote:

> Marc,
>
> I mostly agree but you have a little history out of order.  Apple and
> Franklin really are important here.  More inline...
>
> On Thu, Jun 30, 2016 at 7:16 PM, Marc Rochkind <rochkind at basepath.com
> <javascript:_e(%7B%7D,'cvml','rochkind at basepath.com');>> wrote:
>
>> 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.
>>
> ​Hang on that it was not quite that simple.   In fact IBM did publish
> everything because that was what all the PC folks did at the time.   As did
> IBM themselves in their mainframes.   Remember when the PC was originally
> developed, Judge Green has not yet left IBM from its bondage.​   So IBM was
> very careful in those days to follow industry norms.   The PC folks (like
> Apple, Altair, Cromemco et al) published the schematics and the ROM
> listings.  The OS's and higher level tools were closed but the rest tended
> to be generally available so IBM followed suit.
>
>
>
>
>
>> ​....​
>>  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.
>>
> ​This post the Franklin Computer case.​  Clones of Apple II sprung up,
> with CPU motherboards coming from Taiwan.   Hey I made an Apple II clone,
> as well as an Xerox 820 clone in those days myself (I may still have the
> later).
>
> Franklin Computer of Philadelphia started to sell their Apple II to run
> Visacalc - which was the "killer app" of the day (note a theme here).  Jobs
> did not like it and took them to court.  I actually knew the main attorney
> for Franklin at the time (one of the few big cases he even lost).   Apple
> won because it was the contents of the ROM (bit for bit) that was found to
> be identical.   The question became could you "copyright" the bits. [There
> is a whole side discussion about what the memory chip guys of that day did
> to try to keep people from copying them BTW].
>
> Anyway, once that became case law, the concept of a "clean room" was
> created.  As you say, Phoenix did a remarkable job.   BTW:  in an
> interested side note, years later, IBM sold Phoenix its BIOS and started to
> use theirs when the Phoenix BIOS became the gold standard.
>
>
>
>>
>> As for the computer hardware, it was just Intel parts
>>
> ​Motorola, WD, and TI parts originally.​
>
>
>
>
>> 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.
>>
> ​If they had not published the original material, I suspect it would have
> been far, far harder and less attractive.   But also remember, clone in the
> IBM land was already around.  Amdahl was selling like hot cakes.  IBM had
> learned that with the clone market, they sold more of their own product.
> It was an interesting business view.   The pie was getting bigger faster,
> so they got a larger amount of pie, even though the percentage of the pie
> got smaller.​  So IBM made more money.
>
> This was a lesson a lot of companies, particularly computer firms, never
> quite understood.   Having a weak, buy alive competitor is better than no
> competition.
>
>
>
>
>>
>>
>> There were a lot of PCs in the early 1980s that weren't clones.
>>
> ​Absolutely.​  But if the OS has been reasonable and had be able to hide
> the differences (and you not be able to go directly to HW addresses etc..)
> this would have been less of an issue.
>
>
>
>
>> ​...
>> DEC, which had their own weird version of a PC, was the worst.
>>
> ​No doubt.​
>
>
>
>> 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.
>>
> ​Truth is folks built systems that swapped to floppies (and cassette tape
> et al) in those days.  Originally Magix was going to be in that same camp
> when it was a "G-job" by Roger and myself.  When our boss funded its the
> first thing we did was add a 10M disk.​
>
>
>
>
>> ​... ​
>> To get the screen speed on a PC, the application had to own the hardware.
>>
> ​That was a deficiency of the PC HW design.   Other systems, such as the
> Magnolia and later Apollo/Masscomp/Sun, showed you could have fine speed
> with out having to do that.  Also in "PC land" consider when the '20 Mac
> came out and Apple started to get religion (as did NeXT shortly there
> after).
>
> You could do it, but the original PC designs were sloppy and did not care
> -- the feeling was that extra HW (and SW to support) was unnecessary.
> In many ways, the original PC guys were right given how far and how long
> those systems lived.   But it was painful for the SW building as you
> pointed out.    You should not have had to do such "unnatural" or "unsafe"
> acts.
>
>
>
>
>> UNIX insists on standing between the application and the hardware.
>>
> ​As it should ;-) ​It required  good HW under the covers and then UNIX
> drivers that did the the right things.  In the same time frame as the PC
> was developed it was definitely possible and would not have cost more.​
>
>
>
>
>> In PC land that would be unacceptable.
>>
> ​Only because the HW sucked and the OS did not have the right types of
> structures to make it work.​
>
> Seriously, Marc I get it and you are better man for dealing with the craziness
> of the day.  Many of the rest of us would not at the time, and until we got
> "real HW" did not mess that much with it.  Then again, I did not care to
> run a VisaCalc or a Word Perfect :-)
>
> Clem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/ad177082/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[John Cowan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

Clem Cole scripsit:

> ​Truth is folks built systems that swapped to floppies (and cassette tape
> et al) in those days.  

Indeed, the PDP-8 system I cut my teeth on swapped (infrequently) to DECtape,
which is essentially a floppy drive without random access.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
There is / One art / No more / No less
To do / All things / With art- / -Lessness          --Piet Hein

[TUHS] Algol68 vs. C at Bell Labs

[Dave Horsfall]

On Thu, 30 Jun 2016, John Cowan wrote:

> Indeed, the PDP-8 system I cut my teeth on swapped (infrequently) to 
> DECtape, which is essentially a floppy drive without random access.

DECtape was indeed random access; individual blocks could be addressed.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Algol68 vs. C at Bell Labs

[Ronald Natalie]

Yep, you could mount dectapes as filesystems, but you were not getting the greatest performance when you had to wait for it to rewind to update the superblock.

> On Jul 4, 2016, at 3:23 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Thu, 30 Jun 2016, John Cowan wrote:
> 
>> Indeed, the PDP-8 system I cut my teeth on swapped (infrequently) to 
>> DECtape, which is essentially a floppy drive without random access.
> 
> DECtape was indeed random access; individual blocks could be addressed.
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Algol68 vs. C at Bell Labs

[Nemo]

On 30 June 2016 at 20:38, Clem Cole <clemc at ccc.com> wrote (in part):
> Marc,
>
[...]
> Seriously, Marc I get it and you are better man for dealing with the
> craziness of the day.  Many of the rest of us would not at the time, and
> until we got "real HW" did not mess that much with it.

Anyone remember Desqview/X?  A strange beast, running some window
manager on X on a PC. They made available a variant of gcc and you
could actually compile some X stuff.  I say "some" because I tried
compiling something by running xmkmf+make  and went back to laying
subfloor in an adjacent room.  A few minutes later, I heard the PC
rebooting.  The underlying file system was still DOS and thus 8.3
names.  The source included headers that differed in the 9th place and
the stack eventually blew.

N.

[TUHS] Algol68 vs. C at Bell Labs

[Kurt H Maier]

On Thu, Jun 30, 2016 at 10:35:27PM -0400, Nemo wrote:
> 
> Anyone remember Desqview/X? 

The best feature that software had was it let you run Windows programs
from the machine running DV/X on a unix workstation.  It was the only
reason anyone used the Sun machines in one of the labs when I first got
to college.

khm

[TUHS] Algol68 vs. C at Bell Labs

[Lyndon Nerenberg]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]


> On Jun 30, 2016, at 5:38 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> ​Hang on that it was not quite that simple.   In fact IBM did publish everything because that was what all the PC folks did at the time.   As did IBM themselves in their mainframes.   Remember when the PC was originally developed, Judge Green has not yet left IBM from its bondage.​   So IBM was very careful in those days to follow industry norms.   The PC folks (like Apple, Altair, Cromemco et al) published the schematics and the ROM listings.  The OS's and higher level tools were closed but the rest tended to be generally available so IBM followed suit.

But IBM had long stopped publishing source for VM/360 by that point.  They were quite aware by the time of ??-DOS that copyright applied to source code.

And by then there were copyright notices being slapped all over BIOS code.  I remember seeing it in S-100 systems at the time.

[TUHS] MS-DOS

[William Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

>>​...​why didn't they have a more capable kernel than MS-DOS?
​>I don't think they cared. or felt it was needed at the time (I disagreed then and still do).

MS-DOS was a better choice at the time than Unix. It had to fit on floppies, and was very simple.

“Unix is a system administrations nightmare” — dmr

Actually, MS-DOS was a runtime system, not an operating system, despite the last two letters of its name.
This is a term of art lost to antiquity.
Run time systems offered a minimum of features: a loader, a file system, a crappy, built-in shell,
I/O for keyboards, tape, screens, crude memory management, etc. No multiuser, no network stacks, no separate processes (mostly). DEC had several (RT11, RSTS, RSX) and the line is perhaps a little fuzzy: they were getting operating-ish.

It all had to fit on a floppy (do I remember correctly that the original floppyies, SSSD, were 90KB?), run
flight simulator and some business apps.  MSDOS lasted a decade, and served the PC world well, for all its
crapiness.  Win 3.1 was an attempt at an OS, and Win 95 an actual one, with a network stack and everything.

>I agree with 90% of what he says, but not about Algol 68.  He obviously
>has a strong preference for small languages: it would be interesting
>to see his uncensored opinions of C++, the Godzilla of our day as Ada

I’d be astonished if he had anything good at all to say about C++.

He’s still around…you could ask him...

[TUHS] MS-DOS

[Marc Rochkind]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]

Bill: "MS-DOS was a runtime system, not an operating system"

Well said... that's completely true.

Those original floppies were I believe 160K. If you paid extra, the box
would hold two drives. Later, IBM introduced double-sided drives, at 320K
each.

The XT model, with a built-in hard drive (10MB as I recall) came out
one-and-a-half years after the original, in 1983. With it came MS-DOS 2.0,
with a hierarchical file system.

Since the forward slash was used for command-line options, paths used a
backwards slash.

--Marc

On Fri, Jul 1, 2016 at 6:47 AM, William Cheswick <ches at cheswick.com> wrote:

> >>​...​why didn't they have a more capable kernel than MS-DOS?
> ​>I don't think they cared. or felt it was needed at the time (I disagreed
> then and still do).
>
> MS-DOS was a better choice at the time than Unix. It had to fit on
> floppies, and was very simple.
>
> “Unix is a system administrations nightmare” — dmr
>
> Actually, MS-DOS was a runtime system, not an operating system, despite
> the last two letters of its name.
> This is a term of art lost to antiquity.
> Run time systems offered a minimum of features: a loader, a file system, a
> crappy, built-in shell,
> I/O for keyboards, tape, screens, crude memory management, etc. No
> multiuser, no network stacks, no separate processes (mostly). DEC had
> several (RT11, RSTS, RSX) and the line is perhaps a little fuzzy: they were
> getting operating-ish.
>
> It all had to fit on a floppy (do I remember correctly that the original
> floppyies, SSSD, were 90KB?), run
> flight simulator and some business apps.  MSDOS lasted a decade, and
> served the PC world well, for all its
> crapiness.  Win 3.1 was an attempt at an OS, and Win 95 an actual one,
> with a network stack and everything.
>
> >I agree with 90% of what he says, but not about Algol 68.  He obviously
> >has a strong preference for small languages: it would be interesting
> >to see his uncensored opinions of C++, the Godzilla of our day as Ada
>
> I’d be astonished if he had anything good at all to say about C++.
>
> He’s still around…you could ask him...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160701/e306ff47/attachment-0001.html>

[TUHS] MS-DOS

[John Cowan]

Marc Rochkind scripsit:

> Since the forward slash was used for command-line options, paths used a
> backwards slash.

This use of forward slashes came into MS-DOS from CP/M, which got it from
the DEC operating systems.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Yes, chili in the eye is bad, but so is your ear.  However, I would
suggest you wash your hands thoroughly before going to the toilet.
        --gadicath

[TUHS] MS-DOS

[Jacob Ritorto]

>
> Marc Rochkind scripsit:
>
> > Since the forward slash was used for command-line options, paths used a
> > backwards slash.



Does anyone besides me bristle at the term "forward slash?"  In my day
(although I'm under fifty), we called them slash and backslash.  The M$
culture seems to encourage this redundant advective as normal parlance.

--jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160701/8093d227/attachment.html>

[TUHS] MS-DOS

[Jacob Goense]

On 2016-07-01 18:27, Jacob Ritorto wrote:
>> Marc Rochkind scripsit:
>> 
>>> Since the forward slash was used for command-line options, paths
>> used a
>>> backwards slash.
> 
> Does anyone besides me bristle at the term "forward slash?"  In my day
> (although I'm under fifty), we called them slash and backslash.  The
> M$ culture seems to encourage this redundant advective as normal
> parlance.

Yes, but not but not when used for emphasis.

[TUHS] MS-DOS

[John Cowan]

Jacob Ritorto scripsit:

> Does anyone besides me bristle at the term "forward slash?"  In my day
> (although I'm under fifty), we called them slash and backslash.  The M$
> culture seems to encourage this redundant advective as normal parlance.

I encourage it, after hearing people say "Aitch tee tee pee, colon,
backslash, backslash, ...."

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash,
The day and hour soon are coming / When all the IT folks say "Gosh!"
It isn't from a clever lawsuit / That Windowsland will finally fall,
But thousands writing open source code / Like mice who nibble through a wall.
        --The Linux-nationale by Greg Baker

[TUHS] MS-DOS

[Steve Nickolas]

On Fri, 1 Jul 2016, John Cowan wrote:

> Jacob Ritorto scripsit:
>
>> Does anyone besides me bristle at the term "forward slash?"  In my day
>> (although I'm under fifty), we called them slash and backslash.  The M$
>> culture seems to encourage this redundant advective as normal parlance.
>
> I encourage it, after hearing people say "Aitch tee tee pee, colon,
> backslash, backslash, ...."
>
>

Oy gevalt. *crumbles to dust*

-uso.

[TUHS] MS-DOS

[Kurt H Maier]

On Fri, Jul 01, 2016 at 07:44:09PM -0400, John Cowan wrote:
> Jacob Ritorto scripsit:
> 
> > Does anyone besides me bristle at the term "forward slash?"  In my day
> > (although I'm under fifty), we called them slash and backslash.  The M$
> > culture seems to encourage this redundant advective as normal parlance.
> 
> I encourage it, after hearing people say "Aitch tee tee pee, colon,
> backslash, backslash, ...."
> 

NPR did this on a national basis for many, many years.

khm

[TUHS] MS-DOS

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

On Fri, 1 Jul 2016, Jacob Ritorto wrote:

> Does anyone besides me bristle at the term "forward slash?"  In my day 
> (although I'm under fifty), we called them slash and backslash.  The M$ 
> culture seems to encourage this redundant advective as normal parlance.

In my day, it was "slash" and "slosh" (you need to be Australian to 
understand).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] MS-DOS

[Greg 'groggy' Lehey]

On Friday,  1 July 2016 at 18:27:02 -0400, Jacob Ritorto wrote:
>>
>> Marc Rochkind scripsit:
>>
>>> Since the forward slash was used for command-line options, paths used a
>>> backwards slash.
>
> Does anyone besides me bristle at the term "forward slash?"

Does anybody not?  I've even written a Rant about it:
http://www.lemis.com/grog/Rant/bad-language.php#forward-slash

As I say there, I thought it might be an Australianism.  Dave
Horsefall clearly has other views.  Either way, it makes me twitch
every time I hear it.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160702/15fcd776/attachment.sig>

[TUHS] MS-DOS

[Dave Horsfall]

On Sat, 2 Jul 2016, Greg 'groggy' Lehey wrote:

[ backslash vs. slosh ]

> As I say there, I thought it might be an Australianism.  Dave Horsefall 
> clearly has other views.  Either way, it makes me twitch every time I 
> hear it.

Please, no "e" in "Horsfall" (although it is named after an old 
Anglo/Saxon word, referring to someone who tends horses in a field).

I have a mixed English/Scottish background (with Aussie citizenship), if 
that helps to explain my weird turns of phrase...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] MS-DOS

[Dave Horsfall]

On Fri, 1 Jul 2016, Marc Rochkind wrote:

> Those original floppies were I believe 160K. If you paid extra, the box 
> would hold two drives. Later, IBM introduced double-sided drives, at 
> 320K each.

Those in the know, of course, simply put a notch on the opposite side.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] MS-DOS

[Steve Nickolas]

On Sat, 2 Jul 2016, Dave Horsfall wrote:

> On Fri, 1 Jul 2016, Marc Rochkind wrote:
>
>> Those original floppies were I believe 160K. If you paid extra, the box
>> would hold two drives. Later, IBM introduced double-sided drives, at
>> 320K each.
>
> Those in the know, of course, simply put a notch on the opposite side.

Well, yeah, if the drive let you. I did that on the Apple ][ all the time.

But try that on a 5150 and you get "Drive not ready". :/

-uso.

[TUHS] MS-DOS

[SZIGETI Szabolcs]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

Hi,

I think that only worked on the Commodore 64 and likes, where the drive did
not use the index hole to identify the start of sectors/tracks. Punching a
hole there was much harder operation, than cutting a new write protect
notch.

Szanolcs
2016.07.02. 2:16 ezt írta ("Dave Horsfall" <dave at horsfall.org>):

> On Fri, 1 Jul 2016, Marc Rochkind wrote:
>
> > Those original floppies were I believe 160K. If you paid extra, the box
> > would hold two drives. Later, IBM introduced double-sided drives, at
> > 320K each.
>
> Those in the know, of course, simply put a notch on the opposite side.
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160702/a08ae66a/attachment.html>

[TUHS] MS-DOS

[Brantley Coile]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

The dual notch worked on Apple, as it didn’t use the index hole either. Woz didn’t see any sense in the index hole. This scheme only worked after the media for all the disks were two sided, oxide on both sides of the mylar. At first they were made from the same sheets as 1/2” magnetic tape, which has oxide on only one side.

My first floppy drive was in 1978 and it sure beat paper tape!

  Brantley Coile

> On Jul 2, 2016, at 12:37 AM, SZIGETI Szabolcs <szigiszabolcs at gmail.com> wrote:
> 
> Hi,
> 
> I think that only worked on the Commodore 64 and likes, where the drive did not use the index hole to identify the start of sectors/tracks. Punching a hole there was much harder operation, than cutting a new write protect notch.
> 
> Szanolcs
> 
> 2016.07.02. 2:16 ezt írta ("Dave Horsfall" <dave at horsfall.org>):
> On Fri, 1 Jul 2016, Marc Rochkind wrote:
> 
> > Those original floppies were I believe 160K. If you paid extra, the box
> > would hold two drives. Later, IBM introduced double-sided drives, at
> > 320K each.
> 
> Those in the know, of course, simply put a notch on the opposite side.
> 
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] MS-DOS

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5016 bytes --]

On Fri, Jul 1, 2016 at 8:47 AM, William Cheswick <ches at cheswick.com> wrote:
>
>
> MS-DOS was a better choice at the time than Unix.

​Mumble - the question is what is UNIX.  When comparing MS-DOS to UNIX, I'm
talking about the kernel and the programming API.   Unix as a Kernel could
be very small.​  You might not have had as many commands as we do today
/{,usr}/*bin but it could and did fit.   We ran V7 off floppies on LSI-11s
in those days.   It worked just fine.



> It had to fit on floppies, and was very simple.
>
​UNIX could (and did) at the time --   by the time of the AT (which was
when the PC's hockey stick curve took off) an 5.25" floppy had a capacity
of 1.44M.  An RK05, the V6 and V7 standard,  was 2.5 M which is a 40% loss
of space, but it was do-able.  We also know swapping would have been
slower, but again, had been and was done.  I will say, I used to have an 8"
floppy insides hanging over my desk at one point.  You see that there is no
magnetic material left near the center -- where the i-list was.



>
> “Unix is a system administrations nightmare” — dmr
>
​+1 -- this would have been an issue, particularly pre-Goble work on
getting the write ordering correct.  Halts and crashes trashed the FS and
that was an issue!!​  But it was fixed when people cared, and I suspect if
a Unix-ish system had been on the low end, it would have been addressed.




>
> Actually, MS-DOS was a runtime system, not an operating system, despite
> the last two letters of its name.
>
​Amen​.  I use the words "executive."  Or as I have said, it was really
agreement between applications programs on how modify the disk structures
and what could be left in what places in main memory.  As Marc apply points
out, applications >>had to<< by-pass MS-DOS because the HW was not very
good and there really were not good services from the "OS" provided.




> This is a term of art lost to antiquity.
>
​Amen -- sad and very important. ​




> Run time systems offered a minimum of features: a loader, a file system, a
> crappy, built-in shell,
> I/O for keyboards, tape, screens, crude memory management, etc.

And most importantly, were based around an agreement between programs, but
that agreement had no way to be enforced.​



> No multiuser, no network stacks, no separate processes (mostly).

​Networking not so much.  You definitely could (and people did/do) add
networking to executives.  In those days, DEC has DECnet for their systems
(including MS-DOS) and today in the IoT world, I use many of my Arduino's
with network connections.  But I the programing is very much like it was in
my DOS-8/DOS-11/RT-11 days.



> DEC had several (RT11, RSTS, RSX) and the line is perhaps a little fuzzy:
> they were getting operating-ish.
>
​Be careful here Ches.  RT-11 and DOS-11 meet your (and my definitions).
But RSTS and RSX were multi-users and ran (run) protected mode, have/had
full networking stacks etc.  [There is even a lively network of historic
DEC users that to this day have those systems running and available on the
Internet and few member of which lurk and even sometimes comment on this
mailing list].




>
> It all had to fit on a floppy (do I remember correctly that the original
> floppyies, SSSD, were 90KB?), run
> flight simulator and some business apps.

​We ran V7 on 8" floppies (SA800's from Shugart Associates IIRC).  These
were ~ 256K each.  You did have to swap disks in/out a little as Marc
described.   You booted from one Floppy and replaced it with a "root" FS
floppy after the OS loaded.   But it all could and did fit.  You had ad
editor, the compilers, etc.

That said, no graphics files or other stuff   Which as you point out was
important.




> MSDOS lasted a decade, and served the PC world well, for all its
> ​ ​
> crapiness.

​I basically agree.   Although I think it could have been a UNIX-like
substance just as easily >>if<< people had cared.   They key point is that
they did not:  MS-DOS was good enough for what the market needed, and it
was not economically interesting to try supplant it.   The PC (together
with MS-DOS) was a classic "Christensen​ style disruption" to the
minicomputer industry.  As the good Professor points out, the PC was not as
technically good as the technology it replaced, but it was served a new
market that did not care and was good enough for it.



> Win 3.1 was an attempt at an OS, and Win 95 an actual one, with a network
> stack and everything.

​Again - classic Christensen disruption.   The faster moving technology
starts to catch up with the established one.​

So it all come back to my basic point.   The PC and MS-DOS >>could<< have
been made to be in the image of UNIX easily; if people had cared or it was
needed/desired.   But economics caused it to stay in "all its crapiness"
not technology.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160701/55d13a43/attachment.html>

[TUHS] MS-DOS

[Steve Nickolas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

On Fri, 1 Jul 2016, Clem Cole wrote:

> ​Networking not so much.  You definitely could (and people did/do) add
> networking to executives.  In those days, DEC has DECnet for their systems
> (including MS-DOS) and today in the IoT world, I use many of my Arduino's
> with network connections.  But I the programing is very much like it was in
> my DOS-8/DOS-11/RT-11 days.

I've seen TSR network stacks for MS-DOS; I don't *use* such, but they 
exist.

> ​We ran V7 on 8" floppies (SA800's from Shugart Associates IIRC).  These
> were ~ 256K each.  You did have to swap disks in/out a little as Marc
> described.   You booted from one Floppy and replaced it with a "root" FS
> floppy after the OS loaded.   But it all could and did fit.  You had ad
> editor, the compilers, etc.

I think that's how Minix worked on 5.25" floppies too, if I remember how I 
got it up on my old Tandy 1000EX.

> So it all come back to my basic point.   The PC and MS-DOS >>could<< have
> been made to be in the image of UNIX easily; if people had cared or it was
> needed/desired.   But economics caused it to stay in "all its crapiness"
> not technology.

I think OS/2 was certainly closer to Unix than MS-DOS was.

-uso.

[TUHS] MS-DOS

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

> 
> I think OS/2 was certainly closer to Unix than MS-DOS was.
> 
Mostly it had the ugliness of both systems.    The presentation manager and various other aspects got points for the concept, but the implementation was really far from robust.    You spent a lot of time hard-rebooting the the thing when it got wedged.   I was so happy to just switch to AIX on all the PS/2s.    One of my contracts was to port AIX to the i860 on a couple of add in cards (the IBM Wizard and then subsequently the W4).   We actually started with the 370 version of the AIX kernel (closer than the i386 version).    Still it was fun because were were running two UNIXes per box:  one on the i860 and the other on the i386.   The TCF (borrowed from the UCLA Locus system) made it all seamlessly move back and forth.    We even had it boogeying with a 370 when we were working at IBM’s Palo Alto center.

[TUHS] MS-DOS

[Steve Nickolas]

On Sat, 2 Jul 2016, Ronald Natalie wrote:

>>
>> I think OS/2 was certainly closer to Unix than MS-DOS was.
>>
> Mostly it had the ugliness of both systems.

Not gonna deny that, having been tinkering around with porting stuff to 
the earliest versions of OS/2 lately.

(Actually, I was trying to see if I could make a sort of quasi-'nix out of 
OS/2 1.0 using Watcom. ;) Haven't been doing too well at that because of 
Watcom's limited libc.)

-uso.

[TUHS] MS-DOS

[Nemo]

On 2 July 2016 at 11:32, Steve Nickolas <usotsuki at buric.co> wrote:
[...]
> (Actually, I was trying to see if I could make a sort of quasi-'nix out of
> OS/2 1.0 using Watcom. ;) Haven't been doing too well at that because of
> Watcom's limited libc.)

The MKS Toolkit for OS/2 along with gcc+emx gave a second-order
approximation.  (And Warp Connect had 'Net tools, even remote logins
with the former.)

N.

[TUHS] MS-DOS

[Steve Nickolas]

On Sat, 2 Jul 2016, Nemo wrote:

> On 2 July 2016 at 11:32, Steve Nickolas <usotsuki at buric.co> wrote:
> [...]
>> (Actually, I was trying to see if I could make a sort of quasi-'nix out of
>> OS/2 1.0 using Watcom. ;) Haven't been doing too well at that because of
>> Watcom's limited libc.)
>
> The MKS Toolkit for OS/2 along with gcc+emx gave a second-order
> approximation.  (And Warp Connect had 'Net tools, even remote logins
> with the former.)
>
> N.
>

EMX is either the DJGPP/MinGW or the Cygwin of the OS/2 world, right?

-uso.

[TUHS] MS-DOS

[Nemo]

On 2 July 2016 at 21:18, Steve Nickolas <usotsuki at buric.co> wrote:
> On Sat, 2 Jul 2016, Nemo wrote:
[...]
>> The MKS Toolkit for OS/2 along with gcc+emx gave a second-order
>> approximation.  (And Warp Connect had 'Net tools, even remote logins
>> with the former.)
>>
>> N.
>
> EMX is either the DJGPP/MinGW or the Cygwin of the OS/2 world, right?

EMX was the massive undertaking by Eberhard Mattes (then at Stuttgart) to
port UNIX stuff to DOS and then OS/2.  Besides gcc, he also ported (La)TeX,
called emtex.  emacs, and a bunch of GNU stuff.   Except for the file system
restrictions, one could have first-order approximation to UNIX;  later OS/2 file
systems had the option of case-sensitivity and an actual OS, hence a
second-order approximation.  I wrote a lot of stuff at home for compilation on
the dep't Sun.  (By the way, a reasonable OS/2 history may be found here:
http://www.os2museum.com)

Now my two favourite desk boxes are a G5 and an SB2500.

N.

[TUHS] MS-DOS

[John Cowan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

Clem Cole scripsit:

> ​UNIX could (and did) at the time --   by the time of the AT (which was
> when the PC's hockey stick curve took off) an 5.25" floppy had a capacity
> of 1.44M.  An RK05, the V6 and V7 standard,  was 2.5 M which is a 40% loss
> of space, but it was do-able.  

The AT also had the 10 MB disk.  Back when I had an AT, I ran Xenix
System III on it along with the MS C compiler, and was able to create
console-mode programs to run on everyone else's MS-DOS machines.
It's hard to remember/believe that Xenix was a Microsoft product before
DOS was.

> > DEC had several (RT11, RSTS, RSX) and the line is perhaps a little fuzzy:
> > they were getting operating-ish.
> >
> ​Be careful here Ches.  RT-11 and DOS-11 meet your (and my definitions).

I would say even RT-11 is somewhere between executive and OS.  It could
run foreground tasks (hence the name Real Time) if properly sysgenned,
and it had a decent kernel API that you didn't have to bypass.

> But RSTS and RSX were multi-users and ran (run) protected mode, have/had
> full networking stacks etc.  

+1

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
We pledge allegiance to the penguin and to the intellectual property
regime for which he stands, one world under Linux, with free music
and open source software for all.  --Julian Dibbell on Brazil, edited

[TUHS] MS-DOS

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

> 
> The AT also had the 10 MB disk.  Back when I had an AT, I ran Xenix
> System III on it along with the MS C compiler, and was able to create
> console-mode programs to run on everyone else's MS-DOS machines.
> It's hard to remember/believe that Xenix was a Microsoft product before
> DOS was.

I had an Xenix running on my AT as well.

> 
> I would say even RT-11 is somewhere between executive and OS.  It could
> run foreground tasks (hence the name Real Time) if properly sysgenned,
> and it had a decent kernel API that you didn't have to bypass.

I remember the FB (Foreground/Background) version that had more flexibility, even so, it didn’t preempt any running job.   My second paying computer job was writing database software for an RT-11 system.    This was a port of a 370 mainframe application to do lab test management at Hopkins hospital.   This was after the two guys who were tasked with porting it to the Series-1 were having a hard time with it.    Being the wizkid, the IBM guys brought me a 3101 Ascii terminal and asked if I could do anything with it and I connected it to the RT system in lieu of the ADM3 I had been using.

[TUHS] MS-DOS

[Derek Fawcus]

On Fri, Jul 01, 2016 at 08:47:01AM -0400, William Cheswick wrote:
> 
> Actually, MS-DOS was a runtime system, not an operating system, despite the last two letters of its name.
> This is a term of art lost to antiquity.
> Run time systems offered a minimum of features: a loader, a file system, a crappy, built-in shell,
> I/O for keyboards, tape, screens, crude memory management, etc. No multiuser, no network stacks, no separate processes (mostly). DEC had several (RT11, RSTS, RSX) and the line is perhaps a little fuzzy: they were getting operating-ish.

I seem to recall a whole bunch of DOS's for different systems in the early 80's,
where the term seemed to be used in the sense of a System for Operating a Disk.

DF

[TUHS] Algol68 vs. C at Bell Labs

[Peter Jeremy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

On 2016-Jun-30 22:21:27 +0300, Diomidis Spinellis <dds at aueb.gr> wrote:
>First, the 8088 was a 16-bit CPU with an 8-bit data bus in a cheap 
>40-pin package.  This halved the number DRAM chips required and allowed 
>the IBM PC to be easily designed along existing easily-available 8-bit 
>peripherals.  In contrast the 68000 had a 16-bit data bus in a more 
>expensive 64-pin package.  Remember that in the 1980s glue logic was 
>implemented through simple TTL chips, so adopting the 68000 might have 
>doubled the number of chips on the motherboard.

My understanding was that the 8-bit bus was a requirement so IBM could
have a 64KB base model using the then new 64k×1 chips.  IBM also
emasculated the PC so it didn't compete with their existing minis.  The
68008 wasn't available until later (and this would explain why Motorola
pushed the 6809 as a solution).

Both the 8086 and M68k could relatively easily use 8-bit peripherals
(both Intel and Motorola had a range of 8-bit peripherals that they
didn't want to make instantly obsolete).

>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 

Since IBM was buying the software, I'm not sure how much of a driver
this was.  Definitely, porting from 8080 to 8086 was easier but writing
from scratch would be far easier on M68k.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160703/16c609a7/attachment.sig>

[TUHS] Algol68 vs. C at Bell Labs

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

Marc Rochkind <rochkind at basepath.com> wrote:

> Bill Cheswick: "What a different world it would be if IBM had selected the
> M68000 and UCSD Pascal.  Both seemed
> to me to better better choices at the time."
>
> Not for those of us trying to write serious software. The IBM PC came out
> in August, 1981, and I left Bell Labs to write software for it full time
> about 5 months later. At the time, it seemed to me to represent the future,
> and that turned out to be a correct guess.

I worked on a "Microengine" in 1979.

The Microengine was a micro PDP-11 with a modified micro code ROM that directly 
supported to execute p-code.

The machine was running a UCSD pascal based OS and was really fast and powerful.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[TUHS] Algol68 vs. C at Bell Labs

[Lawrence Stewart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

Regarding Pascal for the IBM PC. In its day, Borland Turbo Pascal was particularly fast.

But C existed as well. 

In 1982 I was building an ethernet telephone at PARC and used the 8088, mostly because
they were cheap (due to the PC) and because we had an internal C compiler for it.
I felt C was the necessary language, because that’s what we used on V7 at Stanford.

-L

[TUHS] OS for IBM PC (was: Algol68 vs. C at Bell Labs)

[Norman Wilson]

Greg Lehey:

  And why?  Yes, the 8088 was a reasonably fast processor, so fast that
  they could slow it down a little so that they could use the same
  crystal to create the clock both for the CPU and the USART.  But the
  base system had only 16 kB memory, only a little more than half the
  size of the 6th Edition kernel.  Even without the issue of disks
  (which could potentially have been worked around) it really wasn't big
  enough for a multiprogramming OS.

=====

Those who remember the earliest UNIX (even if few of us have
used it) might disagree with that.  Neither the PDP-7 nor the
PDP-11/20 on which UNIX was born had memory management: a
context switch was a swap.  That would have been pretty slow
on floppies, so perhaps it wouldn't have been saleable, but
it was certainly possible.

In fact Heinz Lycklama revived the idea in the V6 era to
create LSX, a UNIX for the early LSI-11 which had no
memory management and a single ca. 300kiB floppy drive.
It had more memory than the 8088 system, though: 20kiW,
i.e. 40kiB.  Even so, Lycklama did quite a bit of work to
squeeze the kernel down, reduce the number of processes
and context switches, and so on.

Here's a link to one of his papers on the system:

https://www.computer.org/csdl/proceedings/afips/1977/5085/00/50850237.pdf

I suspect it would have been possible to make a XENIX
that would have worked on that hardware.  Whether it
would have worked well enough to sell is another question.

Norman Wilson
Toronto ON

[TUHS] OS for IBM PC (was: Algol68 vs. C at Bell Labs)

[Larry McVoy]

QNX, which wasn't Unix compat at the time but sorta close, in the mid
1980's was very very small and ran just fine on a 80286.  If my memory
serves me correctly I had 4-10 people logged into that box on terminals.

QNX, at least until they put real posix conformance in it, was a really
tiny micro kernel with the rest of the os in processes.  It fit in a 
4K instruction cache with room to spare.

QNX, in my opinion, is the only really interesting and commercially
proven microkernel.

On Mon, Jul 04, 2016 at 12:54:15PM -0400, Norman Wilson wrote:
> Greg Lehey:
> 
>   And why?  Yes, the 8088 was a reasonably fast processor, so fast that
>   they could slow it down a little so that they could use the same
>   crystal to create the clock both for the CPU and the USART.  But the
>   base system had only 16 kB memory, only a little more than half the
>   size of the 6th Edition kernel.  Even without the issue of disks
>   (which could potentially have been worked around) it really wasn't big
>   enough for a multiprogramming OS.
> 
> =====
> 
> Those who remember the earliest UNIX (even if few of us have
> used it) might disagree with that.  Neither the PDP-7 nor the
> PDP-11/20 on which UNIX was born had memory management: a
> context switch was a swap.  That would have been pretty slow
> on floppies, so perhaps it wouldn't have been saleable, but
> it was certainly possible.
> 
> In fact Heinz Lycklama revived the idea in the V6 era to
> create LSX, a UNIX for the early LSI-11 which had no
> memory management and a single ca. 300kiB floppy drive.
> It had more memory than the 8088 system, though: 20kiW,
> i.e. 40kiB.  Even so, Lycklama did quite a bit of work to
> squeeze the kernel down, reduce the number of processes
> and context switches, and so on.
> 
> Here's a link to one of his papers on the system:
> 
> https://www.computer.org/csdl/proceedings/afips/1977/5085/00/50850237.pdf
> 
> I suspect it would have been possible to make a XENIX
> that would have worked on that hardware.  Whether it
> would have worked well enough to sell is another question.
> 
> Norman Wilson
> Toronto ON

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] OS for IBM PC (was: Algol68 vs. C at Bell Labs)

[Clement T. Cole]

Thoth Thucks ....


Actually to give Mike Malcom created Thoth ney QNX was very slick.  I agree with Larry. It was very impressive at the time.  So between Thoth (which was Unix-similar) and Minix (which was V7 Unix API clone) I think it is safe to say there are reasonable existance proofs for saying V7 was quite possible on the 8086/8088 family. 

Sent from my iPad

> On Jul 4, 2016, at 2:13 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> QNX, which wasn't Unix compat at the time but sorta close, in the mid
> 1980's was very very small and ran just fine on a 80286.  If my memory
> serves me correctly I had 4-10 people logged into that box on terminals.
> 
> QNX, at least until they put real posix conformance in it, was a really
> tiny micro kernel with the rest of the os in processes.  It fit in a 
> 4K instruction cache with room to spare.
> 
> QNX, in my opinion, is the only really interesting and commercially
> proven microkernel.
> 
>> On Mon, Jul 04, 2016 at 12:54:15PM -0400, Norman Wilson wrote:
>> Greg Lehey:
>> 
>>  And why?  Yes, the 8088 was a reasonably fast processor, so fast that
>>  they could slow it down a little so that they could use the same
>>  crystal to create the clock both for the CPU and the USART.  But the
>>  base system had only 16 kB memory, only a little more than half the
>>  size of the 6th Edition kernel.  Even without the issue of disks
>>  (which could potentially have been worked around) it really wasn't big
>>  enough for a multiprogramming OS.
>> 
>> =====
>> 
>> Those who remember the earliest UNIX (even if few of us have
>> used it) might disagree with that.  Neither the PDP-7 nor the
>> PDP-11/20 on which UNIX was born had memory management: a
>> context switch was a swap.  That would have been pretty slow
>> on floppies, so perhaps it wouldn't have been saleable, but
>> it was certainly possible.
>> 
>> In fact Heinz Lycklama revived the idea in the V6 era to
>> create LSX, a UNIX for the early LSI-11 which had no
>> memory management and a single ca. 300kiB floppy drive.
>> It had more memory than the 8088 system, though: 20kiW,
>> i.e. 40kiB.  Even so, Lycklama did quite a bit of work to
>> squeeze the kernel down, reduce the number of processes
>> and context switches, and so on.
>> 
>> Here's a link to one of his papers on the system:
>> 
>> https://www.computer.org/csdl/proceedings/afips/1977/5085/00/50850237.pdf
>> 
>> I suspect it would have been possible to make a XENIX
>> that would have worked on that hardware.  Whether it
>> would have worked well enough to sell is another question.
>> 
>> Norman Wilson
>> Toronto ON
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm