I just had a thought one night... I have heard alot about the mis-uses of the goto command because of it's tendency to lead to spagetti code... I was thinking spagetti code would be alright for AI if it was implemented correctly (and I don't mean a programmer figuring out the sequence of jumps)... But what if a program had the ability to program itself with the sequencing of jumps so that you enter the code in certain places and exit in other places and depending on the outcome of the exit, the program could change the sequence of jumps in order to give the intended result... Sorta like a neural net I don't know how easily it is to do self-modifying code from within Windows indeed if it is possible at all... It also came to mind that it might best be done on a dual core processor.

[google] "self-modifying code"

-me

You should check out CoreWars :)

There is a windows Interpretter called WinCore

A program can't change itself. This is because it is running and depends on itself to run the program. When a file is saved it completly wipes the file and then saves over it so the program would glitch. So what you need is another copy of the program and a source. Then a file that rights the new programs.

The program will send a command to the source saying that it needs to change itself and the source will activate the writing program to write over your copy then the copy will send a string saying it is updated and working and it will turn on the second copy and auto enter all values in the first so whatever it's other function is won't be restarted. Then the first will be deactivated and rewriten. Then this will send a string to the source telling it that it is ready to take control back over the program.

C# can generate its own code procedurally, compile it, and run it all without restarting the main app.

And there's nothing stopping you from generating native code on the fly in any other language with direct access to memory, but you'd have to do a lot more work yourself.

Quote:

Original post by tjweb92 A program can't change itself. This is because it is running and depends on itself to run the program. When a file is saved it completly wipes the file and then saves over it so the program would glitch. So what you need is another copy of the program and a source. Then a file that rights the new programs. The program will send a command to the source saying that it needs to change itself and the source will activate the writing program to write over your copy then the copy will send a string saying it is updated and working and it will turn on the second copy and auto enter all values in the first so whatever it's other function is won't be restarted. Then the first will be deactivated and rewriten. Then this will send a string to the source telling it that it is ready to take control back over the program.

You're completely wrong. Machine code can be changed in memory, and it's not impossible (though not easy) to save it back to the file. The reason saving the changes is difficult is twofold, with neither part being the reason you stated. First, windows loads executables by mapping the file to memory, which causes it to be locked as long as it remains open. Luckily, ntdll.dll exports a function that allows you to unmap the executable, but it must be used with caution because simply calling the funciton in a standard executable would cause the code to be unloaded as well, so special measures must be taken in the code to prevent that from happening. The second problem is that executables are not stored on disk in the same layout they are stored in memory, so there would need to be a transformation function to adjust addresses, padding, etc.

In C or C++, making a self-modifying executable would be extremely difficult and would require non-standard extensions to the languages. In machine code/assembly, it's possible but not easy, and in higher level languages such as Common Lisp, the only hard part is saving the changes (and that might not be too hard depending on the implementation).

Code which changes its behaviour over time, is NOT the same as self-modifying code, which literally modifies itself. An AI algorithm could gradually change its behaviour without needing to modify itself.

Self modifying code was used historically to save a bit of space occasionally in assembly language, and as an obfuscation method.

There is no case for self modifying code any more.

Almost as bad, is code-writing-code - of which you could argue, one example is a compiler. But some applications do create code from other code, this code generation is considered a more reasonable technique.

So it might be feasible even, to have an application which outputs source code for a new (modified) version of itself, feeds it into the compiler then chains that. However, it would be very weird :)

Mark

Quote:

Original post by markr [...]So it might be feasible even, to have an application which outputs source code for a new (modified) version of itself, feeds it into the compiler then chains that. However, it would be very weird :)[...]

That's called "reflection", and it's not weird at all. Also, self-modifying code isn't so bad in languages like Lisp, where code is data is code in a proper fashion. Of course, it's not the same as self-modifying machine code, but it does the same thing of modifying code (in place or not depending on the garbage collector etc) without having separate "generate code, compile, replace old code" steps.

The general term for this kind of thing is "metaprogramming", and it's done all the time with templates in C++, preprocessor statements in C, Common Lisp macros, etc.

Java programmers might play with self modifying executable code safely (most bad types of resulting source files, actually arrays, would return error code in compilation thus amount of crashes would be greatly reduced), at the cost of writing theirs own class loader.
Of course there are some isues, like what rights would have that self modified code.

If you are exploring this area, be aware that OS writers (including those writing console operating systems) are slowly backing away from self modifying code.

Basically, it is seen as a security risk. If code is marked as 'read only', the system can trap virus/buffer-exploit attempts at taking control of the system. This is particularly risky on platforms where security is critical (ie the 360 and PS3).

If you go this route, be aware that your code might not work on some platforms in the future.