Path: utzoo!attcan!uunet!lll-winken!ames!haven!purdue!decwrl!pyramid!leadsv!laic!nova!darin
From: darin@nova.laic.uucp (Darin Johnson)
Newsgroups: comp.arch
Subject: Re: Shells everywhere (was Re: Cobol Data Corporation Cyber 180 ...)
Message-ID: <413@laic.UUCP>
Date: 16 Jan 89 23:07:27 GMT
References: <10847@tekecs.TEK.COM> <1185@esunix.UUCP>
Sender: news@laic.UUCP
Reply-To: darin@nova.UUCP (Darin Johnson)
Organization: Lockheed AI Center, Menlo Park
Lines: 28

>From article <10847@tekecs.TEK.COM>, by andrew@frip.gwd.tek.com (Andrew Klossner):
>> []
>> 
>> 	"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.  

Most OS's don't use fork(), it is a very UNIXish call.  A lot do have
exec() type thingies, but they are used for chaining and stuff like
that.  Most OS's run each command in the same process as the command
interpreter.  For example, VAX/VMS loads in new commands in P0 address
space, and the command interpreter (or debugger) resides in P1 space
(I may have P0/1 backwards..).  However, these sorts of command
interpreters can still be considered "shells".  This method is probably
more efficient as fork/exec, but probably not as versatile.

However, writing your own for VMS is no easy task (no documentation).
Even DEC, when they came out with a Bourne Shell look-a-like (which I
expect was designed to turn people off to UNIX), designed it to create
a new process for each command (it caches old processes for some
efficiency) which is horribly inefficient, as process creation is
slow.

Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com)
	"You can't fight in here! This is the war room.."