Conference noted::hackers_v1

    Programs that *only* replicate themselves are probably only of academic
    interest.  Programs that replicate themselves in addition to doing some-
    thing else will, eventually, be of enormous practical interest.

    Consider a program that incorporated some futuristic level of AI such
    that its knowledge base and learning capacity were that of an outstanding
    human being (somewhere between most of us and Einstein).  Now consider
    such a program with the additional capability to self replicate.

    Now consider such a program built for arrays of molecular-level computers
    that can be 'constructed' by specially engineered viruses.  Now consider
    bacteria engineered to serve as a host for the self replication of the
    above bacteria.

    The mind boggles.

    Dave

	How about someone writing a program that not only replicates
	itself but also compiles and executes the replicated version.

	This would be too easy in most interpreted languages (DCL or
	BASIC) so I'd like to see it done in a compiled language.

	Even more fun would be a program in one compiled language
	that would write, compile and execute a program in another
	compiled language that would in turn write, compile and
	execute a duplicate of the first program!

			-J. Wasser

Self-replicating programs can be useful.  Recently, I wanted to set up a
command file with certain properties:

	When one of my batch jobs failed for some reason, it would append
	a few lines to the file.  These lines would be commands that would
	cause the batch job to be resubmitted.

	When the command file was executed, it would resubmit all of the
	batch jobs, delete itself, and then recreate the initial "stub"
	code to which all of the commands are appended.


It is quite simple to write a program which compiles and executes another
which, in turn, compiles and executes the first.  Here it is, in BASIC:

	10 GOTO 10

What is that you are saying?  It doesn't do anything?  Certainly it does,
I have just optimized it, that's all.  Your program would have sat there,
using up CPU-time, compiling and executing, right?  There would be no
output.  My program does the same thing, I have just removed all the
redundant code.

What a program "does" is determined by the output it produces from its
input.


				-- edp

    A minor nit....

    What a program does is determined by its output.  This is dependant
    on the program itself, and often on inputs available at run time.

    The point is that there are programs that 'do things' like prepare
    sine tables, that require no inputs.  A small minority, but a useful
    case to cover.

    Dave

Re .4:

This is not a nit, it is an important case.  But it is covered under my
definition.  A program that prepares sine tables "produces sine tables as
output when given no input".  You have said what output the program produces
when it is fed certain input.  This is a perfectly valid definition of a
program.  The point is, you don't care what happens inside the program.


				-- edp

	I did specify the output of the program I had in mind...
	I don't think "10 goto 10" is anywhere near capable of
	duplicating itself, let alone instructing a compiler
	to compile, load and execute the duplicate.  Since
	your program does not produce the same output, it is
	not a correct implementation :-).

			-John A. Wasser

The following program prints out a copy of itself, compiles that copy, and then
executes that copy.  Of course, I have optimized it, since I would not want to
waste CPU-time.

char*f="char*f=%c%s%c;main(){while(1)printf(f,34,f,34);}";main(){while(1)printf(f,34,f,34);}

This program has been modified from a program which appeared in an earlier note
in this file.


				-- edp

	Oops. I goofed again.  I forgot that DEC programmers don't
	know how to follow a design specification that they haven't
	written themselves.

	I guess the VAX-C Compiler could have been written as a
	null program... it would produce the same terminal output
	as the design called for but it would be so much faster!
	DEC could make a fortune by having the fastest compiler
	available (and the compile times would not be adversely
	affected by program length).  It wouldn't catch syntax
	errors and wouldn't produce any output files but the
	terminal output is all the user cares about, anyway.

	I give up.  I guess the only programming exercise of any
	use is the smallest program that produces a particular
	terminal output.  How about the smallest program to print
	the Constitution of the United States?  If you allow
	for external data, "$TY C" would do it in DCL.  What if
	external files are not allowed (or at least have to be
	counted in the size)?  Size can be measured as source
	file size or object file (.exe) size, whichever you
	prefer.

		-John A. Wasser

10	data '	open "clone.bas" for output as file #1'
20	data '	margin #1, 80'
30	data '	for x=10 to 150 step 10'
40	data '	read a$'
50	data '	print #1,str$(x) + "	data " + chr$(39) + a$ + chr$(39)'
60	data '	next x'
70	data '	restore'
80	data '	for x=160 to 300 step 10'
90	data '	read a$'
100	data '	print #1,str$(x) + a$'
110	data '	next x'
120	data '	close #1'
130	data '	call lib$spawn("basic clone")'
140	data '	call lib$spawn("link clone")'
150	data '	chain "clone"'
160	open "clone.bas" for output as file #1
170	margin #1, 80
180	for x=10 to 150 step 10
190	read a$
200	print #1,str$(x) + "	data " + chr$(39) + a$ + chr$(39)
210	next x
220	restore
230	for x=160 to 300 step 10
240	read a$
250	print #1,str$(x) + a$
260	next x
270	close #1
280	call lib$spawn("basic clone")
290	call lib$spawn("link clone")
300	chain "clone"

Do you want a program that creates an executable image of itself 
without invoking other images?

tom_p

    I don't understand why the goal is to avoid wasting CPU.  In fact,
    I'd like to propose the opposite:

    Write a program that will create two copies of itself, each copy on
    a new node of Easynet, and will cause those two copies to be executed.
    If the program is defeated by security at a node, it should either pick
    another node, or find a novel way of beating security.  It should use
    a little CPU, but should leave as few 'tracks' as possible.

    Now *that's* a hack!

    Dave

	[RE .14]:  Can this program accomplish its mission by manipulating the
behavior of human beings?
#6	(-: :-)\
#6	<_Jym_>\

    Gee, if you allow that, then NOTES-11 wins hands down!

    :-)

    Dave

	NOTES-11?  What's that?
	(Actually, I had VAX NOTES in mind...)
#6	<_Jym_>\

Re: .14 -- I feel really bad about not remembering the name of the guy 
who told the story, but he told this story in the VAX Magic session at 
DECUS in New Orleans (and won a T-shirt)..

Back in DECnet Phase II days, before routing, you had to specify the 
whole path to get anything done.  So he wrote a DCL procedure called
PROBE that would go out and find all the adjacent nodes.  And then he 
got the idea to have it copy itself to the adjacent nodes and run it 
there..  which was all well and good, except for the connectivity in the 
network.. eventually it cloned itself throughout the entire network, and 
this caused no end of aggravation for all concerned.  It even put itself 
onto some RSX and RSTS and the like nodes, where of course it would not 
run.  He, of course, went around and sanitized the VAX nodes, but did 
not realize it was sitting on the RSX nodes, and when an RSX person ran 
across it and could not figure out what it did, it got copied back to a 
VAX node and executed..

I once wrote a couple three programs for a Burroughs Medium System that 
were called LARRY, CURLY, and MOE.  Each simply checked for one other, 
and if it was missing, fired it up, then slept a tiny bit (to allow some 
work to get done).  The operators went crazy trying to kill them off.  
Of course, there was an easy way, but you had to know that while the 
system was executing control statements from the card reader, it was for 
all intents and purposes non-interruptable, so you could put the 
commands to kill off all three programs onto cards and read them in, and 
get the job done.  But there was no way to get it done from the console, 
because you couldn't type fast enough to get all three.

#6Tom

The guy was Paul Winalski.

---Pete

No, it wasn't Paul.  He's not that careless.