Path: utzoo!attcan!uunet!tektronix!tekecs!frip!andrew
From: andrew@frip.gwd.tek.com (Andrew Klossner)
Newsgroups: comp.arch
Subject: Shells everywhere (was Re: Cobol Data Corporation Cyber 180 ...)
Message-ID: <10847@tekecs.TEK.COM>
Date: 12 Jan 89 00:49:23 GMT
References: <28200249@mcdurb> <451@babbage.acc.virginia.edu> <1951@scolex> <1121@raspail.UUCP> <2618@ficc.uu.net> <5657@cbmvax.UUCP>
Sender: andrew@tekecs.TEK.COM
Organization: Tektronix, Wilsonville, Oregon
Lines: 23

[]

	"It should be possible to write a shell for almost any usable
	computer ..."

A shell requires that the system supply fork() and exec(), or perhaps
start_task() (fork and exec combined) system services, or something
analogous and reasonably efficient.  Lots of "usable computers" don't
have these.  Two examples that come to mind are the original PDP-10
running TOPS-10, and IBM CMS under VM/370: each user got exactly one
virtual address space, in which to run exactly one task (although CMS
would let you slip a second small task into a couple of pages reserved
for that purpose, to run while the primary task was suspended).

MSDOS is also a single tasking system (today, at least), but you can
write a shell for it by slipping a few tentacles into the (unprotected)
kernel.  This wouldn't work under TOPS-10, because there's no way for a
shell coexisting with a user task to get control when the task exits.
To do it under CMS, you would have to run a non-shared copy of the
kernel so as to write-enable it; this adds page fault time.

  -=- Andrew Klossner   (uunet!tektronix!hammer!frip!andrew)    [UUCP]
                        (andrew%frip.gwd.tek.com@relay.cs.net)  [ARPA]