Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!midway!gargoyle!chinet!laird
From: laird@chinet.chi.il.us (Laird J. Heal)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW Shell 3.2 wish
Message-ID: <1991Jan06.133928.183@chinet.chi.il.us>
Date: 6 Jan 91 13:39:28 GMT
References: <8797@dog.ee.lbl.gov>, <2577.277bac4f@waikato.ac.nz>
Organization: Chinet - Public Access UNIX
Lines: 33

In article <8797@dog.ee.lbl.gov>, beard@ux5.lbl.gov (Patrick C Beard) writes:

>To continue the thread of MPW 3.2 wishes, here are a few:

>Standard I/O:  have MPW shell act a lot more like a Unix shell by letting tools
>do character at a time i/o.  This would make interactive tools a lot easier
>to write.  Once in a while this is what you want.

This is not possible with how MPW tools operate.  That is, only one tool is ever
executed at once, and the shell is quiescent during tool operation.

This is probably due to the Macintosh Stack operation.  Because the return
address of routines is pushed onto the stack, when a routine that would be
run out of order would return, the stack containing everything run after the
interrupted routine would be popped and everything there would be lost.

It would be possible during a context-switch to copy the stack relevant to
the active routine and restore the stack pertaining to the activating one.
It would also be possible to maintain separate stacks for each MPW tool,
but this would be more wasteful because of the need to have a slop area
for each process and more difficult because of the intrinsic nature of the
ROM routines.  No provision was ever made for dynamic resizing of stacks
under the Macintosh OS (no need to discuss:  where's my MMU?) and it truly
is the best decision to run only one MPW tool at a time.

I have given some thought to what it would take to run some kind of sh as
a Macintosh application.  Considering the need to run in 1024K or 512K or
even less under MultiFinder, you would want to be prepared to copy memory
to disk with feckless abandon, and while it is intellectually stimulating
to consider, it would probably be an exercise in futility to implement.
-- 
Laird J. Heal                           The Usenet is dead!
Here:  laird@chinet.chi.il.us		Long Live the Usenet!