Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!mcsun!unido!laura!trillian.irb!klute
From: klute%trillian.irb@unido.uucp (Rainer Klute)
Newsgroups: comp.sys.atari.st
Subject: Re: Self Modifying code
Summary: Don't do it!
Message-ID: <1697@laura.UUCP>
Date: 27 Oct 89 08:03:42 GMT
References: <46768dca.14a1f@force.UUCP>
Sender: news@laura.UUCP
Reply-To: klute@trillian.irb.informatik.uni-dortmund.de (Rainer Klute)
Organization: University of Dortmund, W-Germany
Lines: 67
Work-Address: Postfach 500500, D-4600 Dortmund 50, Tel. +49 231 755-4663
Home-Address: Vinckeplatz 5,   D-4600 Dortmund 1,  Tel. +49 231 128414
Keywords:

In article <46768dca.14a1f@force.UUCP> covertr@force.UUCP (Richard E. 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.
>
>1) Write the data to an external file (*.CFG), but now
>you have to maintain a PRG, a RSC and a CFG file. Clumsy.
>
>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, no, no! Never write self-modifying code!

1. Self-modifying code is very bad style. It is difficult to
   write and even more difficult to understand. Programs that
   modify itself tend to be unmaintainable.

2. A lot of machines do not allow you to modify a program file
   for security aspects. Consider everyone on a multiuser
   system would be allowed to modify any file. Sure, this is
   not true for the Atari ST, but one should learn to do it the
   right way. Spend some time to figure out how to do it on e.
   g. a Unix system and you can to it equivalently on the ST.
   (Slight simplification here, but you got the idea, right?)

3. On a related topic: Several systems do not even allow you to
   modify your executing program while it is located in memory.
   You will only be allowed to write to the data portion of the
   program. This is due to the fact that on a multitasking
   system several tasks can execute one single program
   simultaneously. Now, if the program code can not be modified
   by the executing task it is sufficient to load the program
   into core only once, thus gaining a lot of efficiency. (Of
   course each program get it's individual data section.)

4. If you are afraid of virusses don't modify your program
   file. You (the average user) could never tell whether the
   program is modified by a virus or not. There are programs on
   the market (including the PD market) that estimate a certain
   checksum for each program and alarm you if this number
   changes. How could such a program tell if the change is due
   to a virus or not?

5. If you are afraid of virusses write protect your media as
   far as possible. A program that writes to it's program file
   needs to be run from a not write protected disk. This a
   unnessary and an avoidable security hole.

6. In the case you mention it is fully sufficient to maintain a
   .CFG file. Simply write out the following items for each
   button (or other object): index of root object, index of
   object within the root object, current flags of the object.
   Upon start of the program the whole stuff has to be read in
   again and the object flags set accordingly. Simple, isn't it?

If you considered this a flame it may be turned off now :-).

  Dipl.-Inform. Rainer Klute      klute@trillian.irb.informatik.uni-dortmund.de
  Univ. Dortmund, IRB             klute@unido.uucp, klute@unido.bitnet
  Postfach 500500         |)|/    ...uunet!mcvax!unido!klute
D-4600 Dortmund 50        |\|\    Tel.: +49 231 755-4663