Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!topaz!ll-xn!nike!oliveb!3comvax!mykes
From: mykes@3comvax.UUCP (Mike Schwartz)
Newsgroups: net.micro.amiga
Subject: Re: making reentrant code for "resident" programs
Message-ID: <591@3comvax.UUCP>
Date: Tue, 19-Aug-86 00:22:55 EDT
Article-I.D.: 3comvax.591
Posted: Tue Aug 19 00:22:55 1986
Date-Received: Wed, 20-Aug-86 01:40:33 EDT
References: <661@usc-oberon.UUCP> <1468@amiga.amiga.UUCP>
Reply-To: mykes@3comvax.UUCP (Mike Schwartz)
Organization: 3Com Corp; Mountain View, CA
Lines: 79

In article <576@curly.ucla-cs.ARPA> occ4mgk@oac.ucla.edu, cc1@pegasus.UUCP (Michael Gersten) writes:
>This is similar to what someone suggested a while back, namely having a
>program consist mostly of library routines so they would be shared.
>
>The benefit of arrainging the program as library routines is that
>A. They get kicked out of memory when needed
>B. They can use globals
>How? Simple. First, when a task does an open library, the open routine
>allocates a block for that tasks globals. Second, all references in the
>source to globals are macro's that expand to a subroutine call. Third,
>all routines that use globals are surrounded by forbit/permit pairs.
>
>This allows all parts of a program that don't do Wait() to be put in as
>libraries.
>
>			Michael Gersten
>      Views expressed here may not be those of the Computer Club, UCLA, or
>  anyone in their left OR right mind.  And that's the name o' that tune.


First, I would like to submit that 'C' programs are not reentrant enough
for the Resident command, simply because of Initialized variables alone.
Consider a program that declares an initialized Window structure and
then modifies some of the structure's elements.  2nd time the program is
jmp'ed to, the initialized data hunks are not initialized anymore.  There
is a solution, and that is to have the Resident command handler copy the
initialized data hunks to a safe place (unknown about by the program), and
then each invocation it would have to initialize the program's known about
hunks...  It is possible, but kinda messy.

Now that I have a 1.5 MB amiga, I can possibly give some food for thought
about CLI's and libraries (more memory really makes a difference folks).

Who cares about Amiga-style libraries?  I think that there is a much easier
way to do things.  What happens if you had a hybrid library/device kind
of PROGRAM.  By program, I mean a 'C' program that you RUN from your
startup-sequence.  Such a 'C' program would not open any windows or printf
to the default screen or anything.  All it would do is create a message port
so that any user's of the thing could send it messages.  It only needs to
process two kinds of messages: Kill yourself, and What is your address?
The purpose of the first message is obvious - to reclaim memory.  The
second tells the user program the address of a jump table to get to
the library routines.  Since the routines themselves can be written in 'C',
the calling program can declare ALL of it's own memory and pass addresses
to the routines in the jump table.  

To remove the need to set up the jump table in assembler language, a
pointer to an array of functions can be passed and the functions called
directly from 'C' that way.  Note that as many user programs can call the
jump table routines at once, since it is fairly simple to make the library
routines re-entrant (not dependant on any global variables).  Each user
program has it's own stack, the subroutines can allocate all the variables
they want to off the caller's stack and still be re-entrant.

One word of caution:  PROCESSES can call such library routines which call
AmigaDos.  TASKS can not call library routines that call AmigaDos.  

OK, so now for my latest CLI idea...  Make a library as above.  Each CLI
(multiple CLIs can be birthed as in AMigaDos) opens its own window/screen
and console devices as desired.  These CLIs can use Andy Finkel's demo
code to alter the CLI IORequest to point to his own window (thanks again
and again Andy).  The main library/device/program should probably service
one last type of message: Execute() the passed program stri.  This should
be the only DOS call ever needed by a CLI.  Don't forget that Execute()
creates a new CLI, so whatever program you run CAN call AmigaDos and do
directories and whatever.  Now, these CLIs can have menus and gadgets and...
and ... and ... and ... and (everything you want that AmigaDos doesn't 
have)!

How about going one step further?  How about a CLI-WORKBENCH?  What if
you automatically assign a predetermined image to each of the obvious
file types (.i, .c, .asm, .a68, .a, .o, .h, ...).  You run the program, and
it does a directory of the current directory and puts the icons on the
screen (using intuition images...).  Then the mouse could be used to select
any of these icons.  Selecting a .c file would invoke EMACS on that .c file.
Selecting a file without extension would run the program.  A .bat file
could mean to EXECUTE it.  You get the idea...

So much for all this Blue Sky stuff.  Later everyone.