[comp.sys.amiga.tech] Making things pure.

mcr@julie.UUCP (Michael Richardson) (01/23/89)

  I really much prefer to use the various csh(ells) out there over native
AmigaDOS commands anyday. When I first heard about ARP, I though SUPER,
great - intelligent commands!! arp.library was nice - all the commands
can use it, but on small systems having a billion little commands that
use a non-Unix syntax drives me crazy. (I have to switch back and forth.
Ever been caught typing `dir' into a SUN console? Embarassing to say the least..)

  But I only have a 1meg 2000, with (alas) one drive (no job) and burning
70K per 3.01A shell is not too wonderfull. The 70K I can afford ONCE.
I ALWAYS `run' everything, start a newcli to test things from (so I can
have my original shell to run dme, db, etc... ) but it would be nicer to just
have (c)shells running in every cli.

  To make a long story short - is anyone working on making any of the
versions of the Dillon shell pure? It has been asked before, but does
anyone have any idea what that means?  No self modifying code, don't
use static intialisation if you are going to modify the variables (i.e.
defaults) and don't pass literal strings to functions that could change
them. But what else? Are my NewWindow structures safe? My menu structures?
How about strings that I use for file names, ...

  The other thing I'd like to make resident (other than cc, ln [Manx] and
make) is a rewritten `rnews' - one that gets run for each article
accepted. A slave of unbatch[fc] rather than a master.








--

  :!mcr!:
  Michael Richardson                     Amiga
                                  v--------+
 UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr  | INTERNET mcr@doe.carleton.ca
 Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10

toebes@sas.UUCP (John Toebes) (01/26/89)

In article <0160.AA0160@julie> mcr@julie.UUCP (Michael Richardson) writes:
>  I really much prefer to use the various csh(ells) out there over native
>AmigaDOS commands anyday. When I first heard about ARP, I though SUPER,
>great - intelligent commands!! arp.library was nice - all the commands
>can use it, but on small systems having a billion little commands that
>use a non-Unix syntax drives me crazy. (I have to switch back and forth.
>Ever been caught typing `dir' into a SUN console? Embarassing to say the least..)
>...
>  To make a long story short - is anyone working on making any of the
>versions of the Dillon shell pure? It has been asked before, but does
>anyone have any idea what that means?  No self modifying code, don't
>use static intialisation if you are going to modify the variables (i.e.
>defaults) and don't pass literal strings to functions that could change
>them. But what else? Are my NewWindow structures safe? My menu structures?
>How about strings that I use for file names, ...
>
>  The other thing I'd like to make resident (other than cc, ln [Manx] and
>make) is a rewritten `rnews' - one that gets run for each article
>accepted. A slave of unbatch[fc] rather than a master.
>  Michael Richardson                     Amiga
Actually there is a fairly trivial method to make a program pure - recompile
it with Lattice 5.0 and link with the cres.o startup.  As long as it is compiled
with the default (-b) option, it doesn't matter what sort of initializations
you do (including taking the address of other parameters) the compiler/linker
will perform all the magic to make it work correctly.  I have taken and made
resident versions of Kermit, PopCLI, VT100, and several other utilities that
I use all the time.  All the major utilities shipped with the 5.0 product are
compiled in this manner to make them PUREly resident.  It works with Bill Hawes
resi that does checksumming of the image.  Even the LS program that Justin
McCormick posted is residentable in this way.

I agree whole-heartedly about making programs resident.  Once you have seen the
outright blazing speed of an amiga with everythig resident you don't want to
go back.  I see that this is one place where the Amiga can really blast away
at the competition.

/*---------------------All standard Disclaimers apply---------------------*/
/*----Working for but not officially representing SAS or Lattice Inc.-----*/
/*----John A. Toebes, VIII             usenet:...!mcnc!rti!sas!toebes-----*/
/*------------------------------------------------------------------------*/