[HECnet] RSTS/E started emitting "?EVTLOG (BLDNIC) -- %Integer error" messages

[Johnny Billquist]

A friend of mine used the word "unexec" for it, which I think is 
actually pretty fitting. It's sort of the complement to the exec() call.

   Johnny

On 2021-11-12 16:59, Johnny Billquist wrote:
> 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.
> 
>    JOhnny
> 
> On 2021-11-12 16:06, Thomas DeBellis wrote:
>> It's not uncommon or it least it didn't used to be.  Here are three 
>> examples:
>>
>> First, I believe early versions of Smalltalk did exactly this.
>>
>> 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.
>>
>> 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.
>>
>> Third, at Columbia, it was used extensively in our chronically CPU 
>> starved environment:
>>
>>   * The EXEC could save the PCL environment (but I think this originally
>>     was part of the CMU implementation)
>>   * 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'
>>   * 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)
>>
>>  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).
>>
>> 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.
>>
>> In these days of multi-gigahertz processors, I don't see the children 
>> discussing it much at all.
>>
>>> ------------------------------------------------------------------------
>>> On 11/12/21 9:24 AM, Paul Koning wrote:
>>>
>>> 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.
>>>     paul
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> On Nov 11, 2021, at 6:22 PM, Johnny Billquist <bqt at softjar.se> 
>>>> 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.
>>>>
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol