🚀 go-pugleaf

Richard Covert writes:

>I have a friend who has written some shareware programs
>(ARCIT, ARCIT Shell, UNARCIT etc ) and he would like to
>make his code self-modifying. IN particular he would like
>to save the state of various buttons that he uses.

Just a minor point:

This isn't technically what "self-modifying code" means.  The term
usually refers to executable code that changes/creates executable code
at run-time.  An example might be a bit of code that writes a certain
number of move instructions into a buffer, then jumps into the buffer.

While self-modifying code can occasionally be useful (perhaps for loop
unrolling), it has two major problems:

   1) It's incredibly difficult to understand, modify, debug, and maintain.
   2) It won't work on machines with instruction caches.

Way back when, self-modifying code was thought to be a really powerful 
technique.  I seem to recall there was quite a debate about its merits,
out of which came the "Harvard architecture", where code and data are
kept in separate places (and never the twain shall meet).

Anyway, I think these days that most computer scientists would agree
that it is simply "tricky" and confusing, and should be avoided.

[Richard's stated options:]

>1) Write the data to an external file (*.CFG), but now
>you have to maintain a PRG, a RSC and a CFG file. Clumsy.

I don't see why this is clumsy.  It makes the program much easier to 
maintain.  It would be even nicer if the config file were human-readable
and editable.  C provides fprintf and fscanf for this sort of thing.
If you use these, every C programmer will know what you're doing right
away.  

>2) Write to the RSC file, but my friend wants to incorporate
>the RSC into the PRG (using RSCTOC or equivalent). So, there
>may not be a RSC to write to.
>
>3) Write to the PRG file. Best of all since you need it to
>run his program!!

No offense, but I really think this is a "sleazy hack".  What's the point of 
doing this?  Then you have to worry about what happens when you 
(heaven forbid) modify the source code and recompile, thereby changing 
the size of the executable.  And, as you pointed out, you have to come
up with some "clever" scheme to make sure you don't clobber something
useful (like executable code) in your binary.  Whatever you come up
with will likely be non-portable as well.

If you don't want people to see the config information, why not put it
in a hidden file?

>[1st suggestion --- store a unique string in the binary and search for it]

Not only is this risky, but it's also going to be slow.  Additionally,
putting things like

	static char	config[1024] = "MAGIC STRING HERE";

in your source seems like one of the easiest ways to bewilder anybody 
looking at the code (including you).

>[2nd suggestion --- reserve space at the end of the binary and lseek]

This isn't risky, but it's still slow.  Here you're going to have to
plow through the whole binary to get to your config data.  Is this
an improvement over simply opening a separate file?

>I am interested in this whole idea.

It's a nifty concept, but I think in practice you'll find that it isn't
worth the trouble it will cause you.

	David Baggett
arpa:	dmb@tis.com