🚀 go-pugleaf

Last night, Stew Rubenstein from Harvard was kind enough to tell me
what he knows about INIT resources.  (IM is silent on the subject.)
In case anybody else is interested, here's what he told me:

During system startup, each INIT resource is loaded and branched to 
via a JSR instruction.  So, an INIT resource is just a piece of code
that ends in RTS and does something useful at system startup.

There are a couple of handy techniques to use with INIT code.
First, if part of the INIT is going to be permanently resident
(e.g., if the INIT installs a system patch), the code to install
the patch is placed at the *end*, with a branch to it at the beginning.
After it's done the installation work, the INIT resource can call the
resource manager to reduce its own size.  So, only the permanently
resident code continues to occupy heap space.

In a similar vein, INIT's that don't want to leave anything behind
can be set up as unpurgeable resources (to protect themselves during
execution), then set themselves purgeable just before exiting.

BTW, RMaker does not have INIT as a native type.  The MDS documentation
doesn't mention INIT, but the Aztec C documentation does.  They explain
that since INIT is much like PROC, just say "TYPE INIT = PROC" (followed
by the info that a PROC description would normally have).

Now for a question: the Aztec C documentation also says that INIT resources
cannot have overlays (no surprise) nor can they have *any initialized data*.
From a brief experiment, it appears that this precludes any use of strings.
If so, is Aztec C essentially useless for constructing INIT's?  How can I
open a file, named resource, or driver?

-- 
Ephraim Vishniac
  [apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac
  vishniac%Wang-Inst@Csnet-Relay