There are a whole lot of superb reasons why code (the instruction set)
should never modify itself----if its compiled into an exe file.  That was
just as true for OS/2 as it was for DOS---but ALOT of DOS programmers did
it any way because either they didn't know any better or it was convenient
and DOS let them do it.   I actually can't think of any programming problem
where there isn't a better way to approach the problem.  If you feel that
your particular problem has no other solution than to change the exe file,
please post it here so we may all be enlightened on it.

If you are changing the instructions set while the program is executing
then what you are really doing is "interpreting" the
instructions.  The right way and the safe, clean way to do this is to
compose your program into 2 parts:  1) the exe file as an interpreter of 2)
data which are in fact instructions that can be created and executed on the
fly.  In other word, write yourself an interpreter. This is neither unusual
or particularly difficult, and it will save you and your users alot of
grief.

Other approaches that might work are pointers to functions, void and
pointer to void datatypes as parameter to functions, etc.   Classes can use
templates, etc. to deat with the unknown and unknoweable.

BTW, REXX and prolog (among many languages) can "interpret"
instructions that are created during runtime.   It is certainly a great
strength in any language.

===
 * KWQ/2 1.2e NR * This tagline stolen by KWQ Mail/2.


--- GEcho 1.00