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

[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 

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

[Greg 'groggy' Lehey]

On Monday,  4 July 2016 at 11:13:30 -0700, Larry McVoy wrote:
>
> QNX, in my opinion, is the only really interesting and commercially
> proven microkernel.

Tandem's Guardian was a microkernel, and a very successful one at
that.  At one point (mid-1980s) Guardian systems were running the
majority of the world's ATMs.

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/20160707/35a36be2/attachment.sig>

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

[John Cowan]

Greg 'groggy' Lehey scripsit:

> Tandem's Guardian was a microkernel, and a very successful one at
> that.  

I doubt if anyone knew or knows that who didn't work there.  I did a
lot of TAL programming on those machines, and I had no clue about the
structure of the kernel.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
The work of Henry James has always seemed divisible by a simple dynastic
arrangement into three reigns: James I, James II, and the Old Pretender.
                --Philip Guedalla

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

[Greg 'groggy' Lehey]

On Thursday,  7 July 2016 at  6:51:08 -0400, John Cowan wrote:
> Greg 'groggy' Lehey scripsit:
>
>> Tandem's Guardian was a microkernel, and a very successful one at
>> that.
>
> I doubt if anyone knew or knows that who didn't work there.

I think so, though it wasn't high on the list of features.  Nor should
it be.  But the message system in particular (for communicating
between kernel processes) makes for a very interesting design.  Adding
networking was as simple as extending the message system beyond the
local cluster, and Tandem was running an internal world-wide network
by the early 1980s.  It makes an interesting (if not particularly
good) comparison with the Internet.

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/20160708/aea76ac3/attachment.sig>

[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

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