<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>It's not uncommon or it least it didn't used to be. Here are
three examples:<br>
</p>
<p>First, I believe early versions of Smalltalk did exactly this.</p>
<p>Second, at WPI, we implemented two commands called <font
size="4"><tt>freeze</tt></font> and <font size="4"><tt>thaw</tt></font>,
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, <font size="4"><tt>freeze</tt></font>, come back later,
<font size="4"><tt>thaw</tt></font> the <font size="4"><tt>.ICE</tt></font>
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
<font size="4"><tt>freeze</tt></font> on your behalf, thus both
freeing up the job slot and not losing your work. Saved me a
bunch of <font size="4"><tt>TECO</tt></font>'ing. It could have
been extended to batch jobs running out of processor time, but I
don't remember if it was.<br>
</p>
<p>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>
</p>
<p>Third, at Columbia, it was used extensively in our chronically
CPU starved environment:</p>
<ul>
<li>The EXEC could save the PCL environment (but I think this
originally was part of the CMU implementation)</li>
<li>The mailing system keeps a binary file of forwarding
bindings. If you edit the text source, the newer write date is
noticed and the binary is 'recompiled'</li>
<li>I lifted the feature for LPTSPL's LPFORM.INI parser when I
realized how often it was getting reparsed (basically after any
idle period between jobs)<br>
</li>
</ul>
<p>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 <font size="4"><tt>JACCT</tt></font> set
unless the existing job had the ability to get that, was <font
size="4"><tt>[1,2]</tt></font> 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 <font
size="4"><tt>FILDDT</tt></font>'ing (or <font size="4"><tt>EXAMINE</tt></font>
and <font size="4"><tt>DEPOSIT</tt></font>, if it came to that).</p>
<p>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.</p>
<p>In these days of multi-gigahertz processors, I don't see the
children discussing it much at all.<br>
</p>
<div class="moz-cite-prefix">
</div>
<blockquote type="cite"
cite="mid:9F2CBE0C-1B2C-4FED-B7E8-13907A2F63B3@comcast.net">
<hr width="100%" size="2">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.
<pre class="moz-quote-pre" wrap="">
paul
<blockquote type="cite"><hr width="100%" size="2"><p>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.
</p></blockquote></pre>
</blockquote>
</body>
</html>