<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I'm not 100% sure, but I don't believe that ITS/Tops-20/TENEX
      Emacs quite does this.  It is built on top of TECO, which you will
      recall as a language that is so terse that it looks like line
      noise.  I don't think it's a very big stretch to compare it a byte
      code interpreter.</p>
    <p>I do not recall that the EMACS libraries that are loaded are not
      <i>quite</i> compiled.  They have all the comments and unnecessary
      white space stripped out, which would, of course speed execution.</p>
    <p>gnuEmacs does a similar thing for the LISP code; it's still
      interpreted as I recall.<br>
    </p>
    <div class="moz-cite-prefix">On 11/12/21 10:59 AM, Johnny Billquist
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0a969799-b6a6-3904-514b-0270e807039a@softjar.se">RMS
      kept the idea alive in Emacs, where even today you fire up the
      core system, load all kind of libraries, and then you do a memory
      dump, which is the runnable Emacs image.
      <br>
      <br>
        JOhnny
      <br>
      <br>
      On 2021-11-12 16:06, Thomas DeBellis wrote:
      <br>
      <blockquote type="cite">It's not uncommon or it least it didn't
        used to be.  Here are three examples:
        <br>
        <br>
        First, I believe early versions of Smalltalk did exactly this.
        <br>
        <br>
        Second, at WPI, we implemented two commands called freeze and
        thaw, which would take all the information in the currently
        running job (AC's, PC, open files, Etc.) and write them into a
        file.  You could ^C, freeze, come back later, thaw the .ICE file
        (frozen job, get it?) and be right where you were.  One common
        use was when a dial up was abruptly disconnected by call
        waiting.  The monitor would notice you were detached and perform
        a freeze on your behalf, thus both freeing up the job slot and
        not losing your work.  Saved me a bunch of TECO'ing.  It could
        have been extended to batch jobs running out of processor time,
        but I don't remember if it was.
        <br>
        <br>
        I liked it so much that I tried to implement it at Columbia for
        Tops-20.  Tried...  I think the problem I ran into was that I
        couldn't find out timers and get the same fork handles.  Or one
        of the problems.  Another was security, which I'll discuss
        below.
        <br>
        <br>
        Third, at Columbia, it was used extensively in our chronically
        CPU starved environment:
        <br>
        <br>
          * The EXEC could save the PCL environment (but I think this
        originally
        <br>
            was part of the CMU implementation)
        <br>
          * The mailing system keeps a binary file of forwarding
        bindings.  If
        <br>
            you edit the text source, the newer write date is noticed
        and the
        <br>
            binary is 'recompiled'
        <br>
          * I lifted the feature for LPTSPL's LPFORM.INI parser when I
        realized
        <br>
            how often it was getting reparsed (basically after any idle
        period
        <br>
            between jobs)
        <br>
        <br>
         From the information security standpoint, you have to consider
        the usage of these kinds of files.  Obviously, you wouldn't want
        to thaw something with JACCT set unless the existing job had the
        ability to get that, was [1,2] without some fairly careful
        checking.  Ditto Tops-20, if the fork had capabilities.  I mean,
        if somebody could get write access to the binary, then they
        could potentially compromise system security with a little
        strategic FILDDT'ing (or EXAMINE and DEPOSIT, if it came to
        that).
        <br>
        <br>
        A 'legitimately' corrupt binary could also crash the fork on
        start up, but I don't recall as we ever fully addressed that.  I
        think a checksum would have been the obvious start, but I guess
        we didn't want to spend the cycles.
        <br>
        <br>
        In these days of multi-gigahertz processors, I don't see the
        children discussing it much at all.
        <br>
        <br>
        <blockquote type="cite">------------------------------------------------------------------------
          <br>
          On 11/12/21 9:24 AM, Paul Koning wrote:
          <br>
          <br>
          That's a bit like how RSX-11/D and IAS boot -- by reloading
          the image of memory when you issued the SAV command. Pretty
          clever: you set things up the way you want them to be, and
          then you make that state persistent.
          <br>
              paul
          <br>
          <blockquote type="cite">------------------------------------------------------------------------
            <br>
            <br>
            On Nov 11, 2021, at 6:22 PM, Johnny Billquist
            <a class="moz-txt-link-rfc2396E" href="mailto:bqt@softjar.se"><bqt@softjar.se></a> wrote: I must admit that I hadn't
            considered the possibility of just saving the core. Which of
            course can accomplish the same thing in a neat way.
            <br>
            <br>
          </blockquote>
        </blockquote>
      </blockquote>
      <br>
    </blockquote>
  </body>
</html>