I thought I should finally just say it.

A couple of months ago, maybe half a year to a year ago, I made what I call a Progranism (cross between the words Program and Organism). The point of the program was to prove my theory that a program could mutate and show signs of evolution by doing so. The project was a success, mind you.

It took several tries before I got a good version of my Progranism. The final version is a win32 app, if I remember correctly. Here is what it does:

1. On run it waits 60000 milliseconds (1 minute)
2. It then creates two copies of itself in the same directory.
3. As it reads through its own file and outputs to one of the copies, it has a 10% chance of making a mistake(mutation), either adding, removing, or changing a byte of machine code. There is also a 1% chance of 2 mistakes.
4. It runs the two new copies, and shuts itself down.

The first "lab" computer I used was not prime feasting grounds for my baby Progranisms, so I switched to a rather decent Win XP computer. The babies grew into ugly, but cool, mutants.

So, what exactly went on? Well, of course the Progranisms multiplied, the system would always max out at 800 processes because then the number of Progranisms being added was equal to the number being removed, due to the ever decreasing CPU power per Progranism. After about 2 hours of running the Progranisms I'd do a cold shutdown, i.e. unplug the comp. The folder with the Progranisms would often have 10,000+ files. I'd find the 800 most recent, non-empty Progranisms, delete the rest, and run what was left.

These tests went on for a long time before I eventually stopped for whatever reason. By the time I had stopped though, the Progranisms had gained some amazing abilities. They now created 3 copies, and multiplied every 10 seconds instead of the original 60. You can see how that was a problem for my computer, heh. Even more amazing was that they had learned how to kill each other...a bit brutal, but they did it. They would delete other Progranisms in the folder, don't ask me how they did it, but they did, and I was fricken amazed when I noticed that they were doing that.

I'm sure they are doing WAY more things, but it's not like I can watch the computer process their code, so a lot of what they do is hidden from me, heh.

They also increased in file size several bytes, I can't remember how many, but it was a fair amount. OH, and one time, a Progranism found its way to my Desktop didn't work though, was what I call a defective Progranism :-\

So, besides this being a really cool project, I think it can also benefit games. How about mutating AI? Create some sort of "Tactical code" and have that mutated, favoring AIs that can score the most points.

So, after this long post, what do you gals/guys think of what this freakish idea? Want to try some Progranisms out for yourself? If anyone is interested I have both the source code I used to make the original Progranism, and I have a set of 800 Progranisms from the last "batch" that was run. OH and I have a couple of Progranisms from my enlargement tests where I tried to breed a Progranism that would grow in file size as fast as possible. So, if anyone here is interested, just ask and I'll whip up a zip file for ya'll.

NOTES:
One thing I should mention is that Progranisms are !DANGEROUS! They mutate their machine code, hence they can do all sorts of things, and overwhelm the system with dieing processes. Occasionally I had to use the Win XP disc to boot and run a scandisk, because Win XP would error on boot . This is why I used a "lab" computer that didn't have important stuff on the HD. That and the Progranisms will likely shorten the life of your HD.

OH, and you may ask why I'm posting about this NOW that it had been like half a year...well...cause I wanted to make a safer and cooler Progranisms 3D game, basically giving the Progranisms a 3D environment to play in...but I have other projects I got to do, so I decided to just let the secret go.

Another Note: I'm not sure this is the right area to post in...seems like it, I mean it is a Game Concept, it isn't exactly Programming related, and since it is a game concept, I don't think it belongs in Off-Topic ordeals...any who, don't yell at me if it's not in the right spot please.

That is incredibly cool - it's basically Darwinian evolution applied to machine code.

I wanted to do a project like this, but I never got around to it.

NICE!!!

Anyways, in practice, just use a simulated GA using your own VM instead of dangerous machine code. Maybve have them modify their LUA source like that. BTW, that is NOT a good idea for a game AI, randomly doing stuff like that.

Well, in the case of AI, of course the concept would need to be advanced more so it doesn't do crazy stuff, heh, but it isn't like it COULDN'T be applied. Also, once Progranisms are taken away from the machine, and attached to a virtual machine, they lose some important concept features, like being able to hack into a fellow Progranism...

Then you need a better VM.

true......anywho...it's cool watching my computer choke on Progranims, hehe, that and, how would they ever gain the ability to spread across a network if they are stuck inside a VM? I'm dumb!

If it was supposed to be anything biological, they can't just kill others. But maybe have them all running in one script space?

Have you read on GAs? You basically make a tree of all your statements (or the machine code, but not as effective), like an if node with a true node and a false node, then mutate them by taking one random section and putting it onto another:

      p1          p2
       |           |
      s1          s2
      /\          /\
    s3  s4      s5  s6
     |  /\      /\   /\
    s7 s8 s9  sa sb sc sd

Then to mutate, pick two random nodes, say s3 and s2, and interchange them:

      p1          p2
       |           |
      s1          s3
      /\           |
     |  s4        s7
     |  /\
     | s8 s9
    s2
    / \
   s5  s6
  /\   /\
sa sb sc sd

It leads to things working more properly more often

interesting....anywho. The one thing I'd like to do is take out the extra junk in the EXE, like error messages and fluff that MSVC puts in there. That was the mutations are more likely to hit the core code, instead of the fluff.

Compile it to pure machine code and have it be a .com file.

Thats really cool, but it seems like you would have to change more than one byte of a program for it to have an effect AND have the program still work. Also it seems like 99.9999% of the programs wouldnt work correctly. Are you just changing one byte every pass?

That's a basic principle of evolution - quantity over quality.

you'd be surprised how much EXE can take before it chokes on itself, heh. Course, I'm sure a lot of the mutations are hitting the "fluff", but the mutations worked, cause the progranisms started deleting files...

It's dangerous letting them run wild like that, though; what if one of them suddenly develops the ability to erase your MBR? You'd be pretty screwed then.

MUWHAHAHAHAHAHA, and so would they, I'm dumb!. Accually, Win XP might protect the MBR? Or maybe I should run them under a non-admin account...that'd be safe.

And suddenly one day, Skynet is born

Interesting idea to meddle with the executable itself instead of the source code

messing with the source code would be hard? sorta...computers aren't usually good at understanding languages other than machine code I'm dumb!. and about skynet, the Progranims are working on it, they said they'd be done by tuesday next week.

So when two of your Progranisms create another Progranism, do they get a Prograsm?

It would be interesting to run these in a controlled environment (i.e. a VM) for a while and see what happens, which ones survive and which don't, etc ... and possibly use those conclusions to draw some more conclusions regarding evolution in general?

I think we would find that the winners are the ones that cheat.

Kick a.s.s idea! I bet this can be done for AI, maybe a "brain" class / neural net that is virtual, that can be screwed up?

Were the chances rand()? Or were they just because machines now a days suck? ^_^

EDIT

How long did it take to write the program? I sure as hell would love to write something like this..Maybe you can give me a basic outline? I mean, how in the hell did it move one to the DESKTOP?

EDIT2
On second thought, can you post the source code here? We could all bennefit from something like that...;D pweaze?

Thats the plan

rand(), I'm dumb!, computers don't make mistakes, coders make mistakes, hehe. It's rather easy to code, I made the first one rather quickly, but the final product took awhile, cause I had to keep running back and forth with diskettes between the main comp and the lab comp.

It got on the desktop cause one of the progranisms got a mutation in its code and truncated the path(the Progranisms folder is on the desktop). Course, the mutation failed OH, I forgot to note a mutation. I coded in an anti-biotic in the Progranisms so if the file Progranisms.AntiBiotic exsists, the progranisms will stop having babies Well, took them awhile, but eventually a strain came about that was immune to this and now they are ALL immune, muwhahahaha. funny stuff.

Like most really good idea's, someone else beat you to it. Look into Artificial Life AI algorithms.

Hmm? Can you post source code? I don't know how I would run the exes I'm dumb!..I wanna try a project like this...hmm..I see a future: Randomly Generated Computers ^_~

I'm uploading the zip file containing the latest progranisms from the standard run and the enlargement tests, but it's a big file so will take a minute. In the mean time: [url http://www.cljy.com/~billy/Progranism Source.zip] That's the source code...now that I look at it, I did some crazy stuff in there...anywho. I'll edit back the other url to the progranisms.

Things like this is really funny!
I did some genetic programming stuff a couple of years ago. Nothing like this. I tried to make my small "organism" to calculate PI. Of course they cheated.
But it wasn't a serious attempt. Just wanted to try it out a little.

I was on a demo party some months ago and one guy talked about this. He also showed some videos of 3d organism trying to walk. Very interesting.

Yes..Very crazy. Is that for MSVC++?

uhhh...sorta kinda, you can easily tear it down into stuff that'll compile elsewhere.

7 Letters. K.I.C.K. A.S.S

Theres a file missing according to MSVC++. ProgranismApp.h is MISSING!

I have a GA app somewhere... lemme see if I can find it...

[url http://www.cljy.com/~billy/Progranism Source.zip]
for the source, updated, forgot two files

[url http://www.cljy.com/~billy/ProgranismsPack 08142003.zip]
for the pack of progranisms. 1600 of 'em, 22mb.

Nice I may want to make something like this, but from William's code.....uhhh..confusion I'm dumb!...Well, its missing a file that is one problem

Hmmm.....am I doing something wrong?

you need the ProgranismApp.cpp file in your project.

Oh, I guess I didn't actually do GA... But I do have a backpropogation nueral network class, and a SOM class, too... Attatched.

and what now with the he's a what? I'm dumb!, explain

..............uhhhh....

Win32 app, not win32 console app, do you want my project files?

Ah okay. That may just help it a bit ......

I believe I have an idea to do something with this. Instead of it being all writing and stuff, maybe I can use this code in an AI class, and then add Allegro stuff so that we can see what they are doing to each other. Then, when they mate/breed/split, they either loose, add, gain, lose, whatever information. Then, the parent is split in half and maybe some information is lost...

Ahhh..I see a nice simulation game comming along :-x

I'm dumb!. Well, I would have coded breeding into the Progranisms, however, I decided not too, cause I left it up to them to figure out how >8)

I think my project idea would be quite interesting..I shall work on it right away

coo, when do you expect a concept demo? I'm dumb!

May be a while...I will first off have to decide if I want to do cloning by RAM or by writing to a file, etc...Hmm..any ideas?

EDIT

Here is an idea. A single bitmap, which it starts out with..It then copies itself into memory, and reads the BITMAP back to itself. Then it changes/adds/deletes 1 pixel of it, shifting everything back or whatever. Ack..I don't know how to modify bitmaps like this! Crap, but it would be a good start.

This way it can also grow big and small, and also change colors

both? store a file counter-part for later loading(when the program closes), and another copy in RAM for interpretting. Course, these suckers multiple like crazy, so be careful about maxing out of RAM and being forced to use the HD anyway.

Now what would be cool is if you could write two seperate programisms and have them interact with each other... Such as requiring that Type A programism must consume Type B programism in order to reproduce. If it cannot find enough of Type A, you could make it stop reproducing.

Another cool thing is if you could implement some form of 'sexual' reproduction... In other words, two programs take %50 of each others code and output it into a new source program. That would be pretty cool, although the chance of Machine Code Mutation is much higher. Too bad there is no way to kill of bad processes from the computer by having them 'die'.

Yes...

Which idea would you like to see better?

- AI simulation. Multiple clones in an app, which write to the HD of themselves, and they clone. But they only last for 2 clone cycles, that way it saves me space. It then also changes it

- Or the bitmap simulation. It changes the bitmap, and maybe splits it up....At diffrent parts?

Other ideas would be loved with care.

EDIT

50% of the A, with the addition/deletion/change.
50% of the B, with the addition/deletion/change.

Thats a good idea..But communicate between 2 is hard, unless I do the enviorment demo I was talkin' about.

like I said before, the Progranisms are suppose to be open-ended, they'll learn to reproduce if they discover how and if it's a good thing, >8). As for that food thing, what I was going to do in Progranisms 3D was about the same thing, pop food around, and the Progranisms multiple every time they eat a peice of food and die after a certain amount of time. Then they'd have to fight over food >8)

Why 3D?

Maybe we should work on a project like this together?

kanzure: I don't get the bitmap idea? surely you'd start off with a nice looking bitmap which would then turn into a mass of random coloured pixels?

or did I not read your post properly..

Hmm... I have an idea, kinda psycho, but it might work...

Have two programs... ProgramA, ProgramB. The two programs interface with each other on the first run, and generate ProgramChild... Program Child Randomly Selects another program and interfaces with it, generating program child 2. Program Child 2 randomly selects one program for deletion, and randomly selects one program to interface with. Generates Child 3... And so forth.

Of course, the deletion could be modified to be just a move to a different directory... But that would eventually get mutated anyway. Maybe you could implement some form of *.DLL File that contains some common rules that you do not want altered on runtime? Of course, if the machine code changes the dll include, your screwed...

yea, it would get messy, and I thought about that too for the 3D thing, and what I came up with was fractals, but I'm not experienced with fractals....Not sure why I choose 3d....*shrugs*

Ok, do evolution of multi-cellurlar organisms:

Have some sort of interface where you can link together systems and have them interact, one would be the reproduction system, and all organisms would start with it, but might lose it, one could be a growth module, which expands, possibly stealing other's modules, and possibly a development module, which merges two organisms into one, and maybe a symbiosis module, which interacts with organisms doing well in one area and stuff.... Hmm... That way you don't have to worry about totally f'ing up the computer.

Now what would be cool is if everyone submitted there own programism and we ran it on someones machine and see how the interact. The only problem is that we REALLY BADLY need some form of 'master' program to monitor everything... That way we can trace what exactly is being changed on some of the runtimes, and if it gets to hectic on the processor, we could trigger Armegeddon or the Ice Age or something...

I thought about DLLs as well, cause one time(this was when I hadn't perfected the Progranism) a strain came up that didn't mutate...but I figure, hey, if they don't want to mutate, then they don't want to mutate, I ain't going to force them Free Will system idea.

P.S. YEa, I know, that last statement is kinda funny cause my name is will...

Ok, somebody write some interface that uses A VM!!!!!!!!! and I'll be happy to offer my system as a test bed. The VM can get whatever information it needs about my system, but can't change nothin important.

Bother me enough (read: ask me nicely) and I just might write you your own machine language to use.

Master program is needed.

Should we do a Program Organic Compition?

Maybe William shall design that one master thingy, and all ours MUST run under that...

CGP: How about using an emulator like Bochs to act as a VM?

QUESTION: Java....how bout that? Can Java access and run files on the computer? Java would be nice, cause it compiles and has tons of checking.

The number one problem is, that in order to avoid massive unrunable applications, they need to be in bytecode. True, we could most likely use java as the VM or something...

Note: Is it just me or is this post getting really long real fast? May I suggest a move to IRC?

We must make sure the Master Program can spawn 2 at once, maybe the first one running while the other one is spawming.

Also, the master program will monitor the top parts where the VITAL crap is, so if that is changed, it is re-changed so it will still run.

X-G: Eh? An ix86 emulator? that'd be kewl, then they could run in protected mode and stuff, not having to worry about an OS or nothin.
But having custom-made VM would be kewl, because you can create all kinds of intresting simulations that might be really wacky.

Seeing as how I need practice writing VMs, I think I'll do it anyways and if people use it, they use it

[edit]
Kanzure: Do you realize how impossibly hard that'll be on WIndows? Too much work.

CG, make sure it can change the vital information so everything will run even if it was already changed..MAKE IT OPEN SOURCE

having to re-write the progranisms for a VM without a C++ compiler will suck, I'm dumb!. I might write a VM...or not, I got to work on my German homework...

Now, if, in essence, we could implement some way to maintain certian portions of the code (Aka. Refrain from having there bytecode edited) this could prove VERY useful.

The only thing I can think if is to find the EXACT INDEX in the file that the vital information starts at, and have the program only alter code beyond that. But, once again, this would mean that a mutation in the code could always mess up the vital information anyway. No matter how you spin it, it is kinda pointless to retain vital code.

One more thing on the process overload... If there is an easy way to kill processes in windows, we could further the evolution of the programs by 'destroying' random processes once the CPU starts choking because of the number of processes.

Ok, plan for the VM, should you like to use it:

Instructions, in ASM like format:

mov     l1, l2      ; Moves l2 to l1
xor     l1, l2, l3  ; XORs l1 with l2, stored in l3
or      l1, l2, l3  ; ORs ...
and     l1, l2, l3  ; ANDs....
not     l1, l2      ; Inverts l1  and stores in l2
cmp     l1, l2      ; Compares l1 with l2.
jl      l1          ; Executes at l1 if the previous cmp had l1 < l2
jg      l1          ; ... l1 > l2
je      l1          ; ... l1 == l2
jmp     l1          ; Continues execution at l1

Anything else?

To keep consistancy, each instruction will be the same size, so programs don't have to worry about that.

Also, you'll note the lack of registers. Also, the code segment is indistingusished from the data segment for extra fun

You've got the order with mov wrong. ANd boolean operations take two parameters as well. And make sure to have aliases for jl, jg, je, etc.

Yup..We need to maybe figure out the vital parts, not DLL crap, but ... other..stuff...

William - can you write a special prog thing that only writes to 1 new file, and runs that 1 new file? That way...well, it wouldn't take up that much memory..

(WORTHLESS 128 MEG OF RAM LAPTOP)

You cant stop the Progranisms once they've stated, trust me. If you start a progranism and wait more than a couple of minutes, you HAVE to do a cold shutdown, they grow so fast you can't kill them all AND once the CPU is maxed, you can't open the task manager. Also, killing random progranisms is bad, because there is no pattern behind the killing, they'll never figure out what's happening and thus can never adapt to it, there must be a method to the destruction, so they can figure out how to counter the threat >8)

Ok, so you don't kill random progranisms, you just kill the progranisms that are the smallest on disk or something...

Or just run it in a VM

X-G: No, the bitwise ops will take 3 params because of the lack of registers.

[edit]
Also, I could do it as a tree instead, prolly be better for this application. Any takers?

How many registers does your VM have? Three is pretty much minimum ...

X-G: The apps are designed to do one thing: Get themselves wasted They shouldn't have registers. They can use already executed code space as registers

[edit]
However I really think the tree application would be better here.

Now what would be funny is if a program 'adapted' to take control of the VM itself and started going Rogue on your system. That would be hillarious.

And, come to think of it, you could implement some form of list in memory of all currently running processes. You could reduce the processor load by only running 10-20 at a time and cycling to another set...

Well, I guess I'm ok with ASM, just as long as you document everything well for us half-non-asm'ers, heh.

CGP: You're going to need the C register at the very least.

Move to IRC, anyone? That way we don't have to keep hitting refresh every 10 seconds, and someone could just log the chat to post it on here...

Well, the tree would be kewl, because there could be a node that decided to change other nodes, and it would work much better and more efficiently than just a string of bytes. Altough, consider other possibilities as well.

Perhaps model an actual cell's function as it joins with others?
Perhaps model a neural network that can rewire itself as other neurons are more active?
Perhaps a box of hairpins that makes shapes of it's own accord?

No idea is too off, here

Carrus: gimme a channel

WOAH, I just remembered something, I made an Emulator of the Shadow I proccessor. heh, anywho, just this topic brought that up.

BTW, If the Shadow I proccessor doesn't seem like a familiar name, it shouldn't be, it was an imaginary proccessor used in the imaginary Classic Fantasy system I was going to emulate. WEIRD huh? Sorry, I was on drugs when I came up with that idea.

Post IRC channel. Log everything. My computer is tooooo sloooowww...

#Progranisms on EFNet if anyone wants to join

arg, I knew I should have learned what irc was. NEVER FEAR, I shall search the web.

dang this music blows

Download Mozilla. It has a built in IRC client.

runs around ahhhh, slow download....mha

must...join! I'm downloadin' hold ur horses...

uhh..done o_O damn that was fast

{EDIT}
Connecting is SLOW! Sigh..

slow for me...

Can't connect error.

Set the IRC network as "All" (Wtf?) and lets just go to #Progranisms

Join EFNet, like, irc.choopa.net or irc.prison.net then join #progranisms

You have to set your network to EFNET then you can join #progranisms. Just try multiple times... Sometimes the servers are annoying, and with the east coast power down, it could be quite a feat to get online...

I wasn't able to connect to EFNet the first time, went the second time though

Meh, I got in.......3rd time is the charm.

Sorry, but I don't understand how you could get this to work. If you randomly change machine code it is highly likely that you will create code that causes
- segment violation exceptions
- unknown opcode exceptions
- other weird errors

Secondly, you need a tonne of generations to get anything useful evolved. 1 generation/minute probably won't give you enough generations.

That's the point, the ones that fail die >8) Win XP wont crash, at least it hasn't yet. And trust me, these progranisms make THOUSANDS of mutations and they evolved

But we need something that won't crash.

That's now Darwinian evolution works. Some times something changes; most often it's bad, some times it's not. The bad mutations die, the good ones survive to make copies of themselves.

Same thing here. You just have to be lucky and run LOTS of copies.

What we need to do is just find a way to prevent those crashes from halting the system completely... If we could do that, it would be one killer application of computers...

Unfortunately, my short progranism code doesn't work, gives me MSVCRT.DLL errors. GDB gives me SIGSEV errors as well...

Well, here is my code. Pretty short, but it should do the job...

Compiles down to 24.96 kb, FYI. If we can get this to work, it should take up a minimum of resources...

And please, don't kick me for using something not completely supported by C (It compiles with GCC... Should be pretty much valid C), I'm more of a C++ person anyway.

FYI: It locks up when trying to perform a binary read open on the source file...

            if (rand()%RATE_OF_MUTATION) {
                c = rand()%256;
            }

That mutates every 9999 out of 10000, btw...

        if (fp = fopen(filename, "wb")) {
            fclose(fp);
        }

What? If the file fails to open properly the close it? huh?

And what happened to the VM?

What I'd do is to have some "silent sectors" in the code, which aren't in use right now. And a lot of jump calls and labels everywhere, so if one of those jump calls gets mutated, and jumps to the "silent code", strange things would happen.

Junk DNA?

Wow....this is sooooo cool! William, you've made up for all your programming/off-topic forum errors!! I'm definatly gonna mess with this stuff!

Sorry... but you guys are absolutley crazy.
First of all: His program is buggy even w/o some random chanes.
Secondly, if you change your program randomly, it's not very hard to wipe out your hd.
Or randomly altering files you don't intend to alter.

If you guys want to do something like this, use VM ware google for "genetic algorithms" and/or "artificial life".

That's why better than playing russian roulette with your computer.

When I read his post I though, ok, I'll shut up and won't flame him. In fact I thought Korval or 23 would do that for me.
Next day the thread had around 90 very positive replies... either youo guys are trying to force him to do even more stupid things and I just didn't get it... or... well.... don't know.

Geez.
If you want to ruin your puter, you should at least make sure the exe header stays intact. That way the exe will be executed, that gives your experiment a better chance to fry your system.

Have fun.

I think I remember saying quite early that this should be done inside a VM - it's the idea that's cool, not the way he's doing it.

http://www.gamleby.net/x-g/guru.gif

We agreed for a VM

- Meh I'm out of the project. In the IRC room they were talking about an ENTIRE operating system for this thing.

Operating system? That's nothing.

You're going to have to implement the entire processor.

X-G: and do all the logic circuits with FPGAs

Yes, they were thinking of also there own byte code language....AHHHHH runs into a brick wall

Kanzure: You realize, of course, that that is what a VM is?

Ahhh, a fresh morning with a fresh cup of Progranisms.

spellcaster, yes, I do realize the risk, but we all have to take risks some time, eh? So far the computer has suffered nothing but some minor harddrive glitches. Now adays the computer is being used as just a plain computer, not a lab computer, and I didn't have to reinstall windows are anything. Now, just cause it hasn't happened yet, doesn't mean it wont happen, I know that. Last night Kanzure, or maybe someone else, was running them and I freaked out and made sure he knew that they we dangerous.

Anywho, I'm not doing anymore pure computer tests, like is being mentioned, we are thinking about making a VM for the thing to play on

grabs gun Ok Computer, do you feel lucky?

I'm purposely staying out of this The parallels are too close to Darwinian Evolutionary Theory (hell, X-G already mentioned it) and putting me near that is a flamewar waiting to happen Needless to say, this isn't going to work unless you lay down strict rules about how it can "mutate" and (as you say) run it in a VM, etc. Of course, in the process you support ID, not ToE ... anyway, yeah. I'm not following well enough to know exactly what you guys are doing, but maybe you'll ultimately end up with some interesting results. In the meanwhile, I won't care, but hey, knock yourselves out It would be interesting if someone could make a simple little game with AI that learns to outsmart you as you play ...

Ok yea, nobody dare say anything about evolution are this thread will really sky rocket. Anywho, I don't like rules in games, never have. I've always been a Free-Will designer for some odd reason, maybe cause it makes betters games, games where you aren't restricted. But, as such, I never coded rules into the Progranisms, because in real life, there really aren't that many rules that HAVE to be followed, there's rules that should be followed, but you don't HAVE to.

Yea, a quick game like that would be cool >8) We need a game where the player is killing hundreds upon hundreds of enemies, hehe.

Well, for some VM nodes, how about these:

• If: If on node returns true, another is executed, otherwise a third.

• Compound: one statement gets executed, then the other. The most common type of node.

• Move: Moves the whole script in the global script's memory space. Things can overlap, causing the script to merge.

• Mutate: Randomly reconstruct part of the program using a random tree.

• Transpose: Randomly switches two tree branches.

• Putpixel: Places a pixel of a determined color on the screen at a position representing the script.

Anything else that might simulate what biological organisms running inside a VM should be able to do to themselveS? Remeber, we are NOT talking classical life, so yes, organisms should be able to randomly mutate themselves.

shrugs

I would just implement basic simple opcodes within a certain memory space.

Ok, CGames, here are some clafifications:

1) The reason the file closes on error, is I'm simulating a 'replication error'. Essentially, if there is a file name collision, just don't write anything...

2) I was just wondering why my code generates seg faults, that is all...

Could anyone help me, please?

And about the VM... We most definately need a VM! It is way to risky to just plug all of this sutff into your machine... You could very easily wipe your hard disk, flood your network with packets, heck... You could do all sorts of wierd junk...

X-G: Simple opcde might not be optimal... It depends on wether you want to picture the programs as living strings of bytes, or as working programs that evolve.

Your choice, but I think I'd need some help deciding what opcodes to use in the former case.

We'll do both? Experiment, see which methods come out best.

Oh, that's why as of previous week my computer keeps crashing (svchost shutdown, RPC shutdown!!! why? it did not do this before).

Why are you doing this with executables? do it like the game of life, inside a program, simulating.

I started reading this thread, thought "cool"
and continued to read.

Now I have an Idea for a very simple
VM/evolution simulation though
I'm not as good a programmer as I want to be:

first: the "play area" is an allegro bitmap
in memory.
There's an "instruction pointer" (x,y) who
points to the pixel wich is the "statement"
or whatever wich is to be executed
and the pixel color is some op code value

255=cmp (compare pixels)
105=and (and pixels)
104=mov (set pixel colour)
054=jmp ("execute" another pixel)

...I hope you get the Idea...

Now the pixel right of the current op code pixel
is the first parameter next pixel=next parameter
then the program only has to read as many
parameters it needs...

Now I know that this will be only one program
and not some sort of breeding between programs
but I think I will give it a try...

Then of course theprogram will display the bitmap
on screen...

I bit confusing but I think I get ya....like basically your saying use bitmaps to store byte-code data, so you can visualize a program's code? heh, that would be cool to watch the Progranisms mutate and see the differences easily.

Is there a way to prevent the "program crashed" dialog from showing up?

Under what? With the progranisms? With progranisms, no, under any other non-mutating program, yea, sort. Inclose all the code in exception handlers.

EDIT:
!WOOT! I found it. I found my Shadow I emulator and the documents I wrote. Now I got to grab a hex editor and start making sure the thing stuff works.

Hmm, unlike spellcaster I don't think this is dangerous but I do think that it's highly unlikely to work. So far there's been no real evidence.

But enough kvetching, here are some suggestions.

1. Don't use a VM. Speed is essential. Instead, create a program that will "fix" a given binary by disassembling it, checking that the opcodes are correct, then reassembling. Bad opcodes can be replaced by nops (0x90). Also, you can remove high-valued immediate operands as they are probably useful in these small proganisms.

With this you could also disable potentially dangerous things like interrupt calls. I've done a similar thing in the past (lost the code now, sorry), and it was surprisingly easy if you work from the opcode tables in the IASDM manuals.

2. During evolution, don't copy progranisms to the hard drive. Keep everything in memory for speed. You can make occasional backups of course.

3. Reduce the size of the progranisms as much as possible and write obvious code yourself for the progranisms to use. Don't leave obvious things for the progranisms to evolve; every new thing that they have to evolve will slow things down by a factor - evolution is trial and error.

4. Try to make a simulation, game or some kind of display so we can actually see evolution happening. For example, some guy evolved some CoreWar warriors once as part of a thesis on evolutionary algorithms. The evolved warriors were close to simple human designs, which was impressive.

5. Create a virus which runs the evolution program as a distributed app. That way you can harness the powers of thousands of computers for evolution.

Or better yet, create a virus that evolves after every replication, so it is a pain in the rear to protect your system from it.... I'm dumb!!

That's be funny.

"CNN has confirmed a new type of computer virus known as Progranism. This new type of virus is expected to be unstopable as its ability to mutate prevents virus scanner detect."

Anywho, naw.

EDIT:
oops, forgot to ask stuff:
damage, how would you keep the Progranisms in memory? What was that word, Terminate and stay Resident..or somethin like that, is that what you mean? Cause if so, I've never done something like that and you'll have to teach me As for disabling stuff: The only problem is that you'd also disable file writing, no? And you'd disable everything USEFUL the Progranism would want, you disable all that, all the progranism can do is preform calculations that we WONT see, I'm dumb!, which defeats the entire purpose.

Also, if I run the Progranisms under a non-admin account under WinXP, isn't that protected? I don't think WinXp would let it do anything if it's under a non-admin account.

try putting it in to a stack the stack register is always in memory just pop the code that is needed

You can't run the stack and the stack is too small?? heh. BTW, I've got a very nice Assembler working that I'm using to generate test code for my Shadow I emulator. So far so good...

Think again. It may not be too bad in a secure operating system, such as WXP or Linux (though it's always possible that a program accidentally exploits a security hole and gains root acces), but it's still a dangerous, if not foolish idea in general.

About ten years ago, I decided it'd be cool to learn how to call interrupt services, so I wrote a BAsIC program that called a number of them in sequence to see what they did (I'm not kidding! I really was that stupid). Fortunately, I managed to knock out the DOS kernel before I formatted my harddrive. It was funny in a pathetic sort of way because Windows continued to run, but couldn't get disk access anymore. The computer was fine when I rebooted, but it did scare the freezing hell out of me.

In which case they're out of date. Self-modifying viruses used to exist back when a virus was more than a VB script running in Outlook. I don't think they were very effective though...

<quote>I bit confusing but I think I get ya....like basically your saying use bitmaps to store byte-code data, so you can visualize a program's code? heh, that would be cool to watch the Progranisms mutate and see the differences easily.<quote>

yeah that sounds like what I meant...
...but the hour was to late for my brain and
english is not my mother tounge:)...

Well, I made an attempt today but it didn't seem
to work as I wanted, something with the srand(time(NULL))
and rand()%max
Well I might try again.
What system do you recommend to test a "!VM"
progranism on? and how can I be sure it won't
mess up my BIOS?

Yep. The first virus I wrote had a section that encrypted the rest of it, so it was impossible to trace, but better than that, the decryptor code changed, too

Unfortunately, a virus has to be small to be unnoticable (not so much nowadays though) so you can't have a large database of possible decryptors to use... In which case there still are some signatures it leaves. Plus, all the methods you find probably are already used. I set off my virus scanner several times

Damage: They are very dangerous. Speed is not essential. You should really be using a VM if you want to have a display: all the organisms will run in the same memory space.

Elver: Wow. You know there's an interrupt that when called, in all likeliness would have writtien over your partition table?

I like my opcodes still, (rather, my nodes) because they alow a lot of freedom, you can add more, the programisms have something more digitally alive rather than digital representations of biological creatures. (No, we shouldn't emulate something like anything biological).

[edit]
RedMarvin: The VM can't do anything dangerous.

well with "!VM" I mean such progranisms
as was shown first here where windows was the VM

Well, seeing as how that isn't a VM, my statement still holds.

redMarvin, you really can't prevent that. Like I've asked twice before though, under a non-admin account does Win XP stop programs from modifing things like that? If it does, then we're safe under that setting

finds a major logical error in the Shadow I's ASM code...

What if your programs suddenly develop the ability to exploit a previously unknown bug in Windows and suddenly gain admin privileges?

I'd be overflowing with joy because they found an unknown windows exploit heh, I'd let them have their fun.

Who needs exploits? Does Admin even do anything to programs? I'm certain there would be simple ways around it. And not unknown to microsoft. Of course, if you just run it in a VM, you DON'T HAVE THAT PROBLEM!!!

I'm trying to run it under bochs, but I'm having a very hard time with bochs. I finally got it to boot with the WinXP disc, but then I got a PANIC error cause by [HD ].... maybe my disc image is too big...

What if, like human will someday, discover something outside the vm and learn how to manipulate it muhahaha. It's kinda like how maybe humans will leave this unverse or something

Muhahaha, like, what i'm also implying is, what if there is a program called NEO! Will you, the architect simply reboot the matrix or what will happen.

You can't get out of the VM, all the Progranisms are batteries and they'll stay that way >8)

Heh. This is kinda neat.

It doesn't really have to be a complete VM, it could just recognise 256 (anyone feeling creative?) assembly-esque commands. Or rather, recognise some primitive maths, memory handling, branching, and file IO.

Of course, this would all be restricted to an array malloc()ed by the VM, and either a folder or a disk image on the HD.

Should it multitask, and allow one Progranism to write to others' memory (ie access violate)? Or would an access violating program get terminated by the VM (as in a real system)?

What I want:
*Multi-tasking VM, 32-bit
*Global memory, can be allocated, but VM does not block access violations, thus allowing for the Progranisms to hack each other.
*Programs in memory, copies of them on the HD
*A max process limit, denying new processes if this limit is hit.

Now, I have a 16-bit Console VM, and I've been upgrading it a bit, but it's still far from what I want...

Now, multiple threads are going to be hard when there is no one memory space for the programs. You'll bsically have a bunch of IPs all taking turns and such.

installing linux on Bochs is taking a long time... I hope it works and that I can figure out how to convert Progranisms to linux, I'm dumb!.

Have any of you guys heard of "Corewars"? It's a game where you write machine-code programs for a VM. All programs are run in a single memory-space. The idea is for your program to kill off all the other programs (by writing non-functioning op-codes in them IIRC) and survive the longest. The VM goes round giving each program a single opcode execution cycle before it goes on to the next program. These programs can spawn multiple processes, but when it's the program's execution cycle, only one of the process gets to execute it's opcode on that cycle (the other processes have to wait for the next cycle of the program).

On some implementations, the 'areana' (the memory where the competing programs are run) is shown graphically. Each program is given a different colour, and the instruction-pointer of the program or process is shown in a lighter shade of the colour.

I'm sure some good old Googling will bring you more information on Corewars and possible implementations for your platform.

AE.

That post reminds me of this GameDev contest. Check out the rest of the forum for more info. Maybe you guys could do something like that

I used to play Corewars at one point! Never was any good though.

That's what I want to do, but writing an emulator isn't easy, so I'm taking other routes and see what I come up with.

It shouldn't be to hard to have a file that handles the 256 bytecode operations? You could go with a format something like this...
ABXXXXXXXXXX

A is the opcode
B is the Number of Following Bytes controled with that opcode (0-255)
X is a value that is used by that opcode....

Just make sure you write your programs in a hex editor, and your set!

And, in the future, you could double the number of supported opcodes by simply making the template like this...
AA

Shouldn't be too hard...

Carrus: Each opcode accepts a set amount of parameters, so the "B" is unnecessary. As for having two-byte opcodes, you would reserve a couple of values for the first byte that signifies that there is another byte following, I believe ...

Ok, I'm not very good at opcodes and I am kinda new at it...

I've worked out a system that uses two opcode flags... I'll post my system when it is up.

I don't understand why the program launches the two children when it's done. I can see why it would, formatically speaking, but I can't find the code that executes the children.

Just tried you proganisms, and it seems cool. Didn't dare run them for more than one cycle, though, but still they managed to put a file named "~" on my desktop way cool, man!

They did? Sweet, never seen that before, hehe.

And as for what calls the children:

WinExec(Temp, SW_SHOW);

I've got a question. Why does the parent's process never finish? Shouldn't it, or is the WinExec function blocking or something?
EDIT: WTF, it used to...

I can't believe you guys are running those. I hope at least you have everything backed up. I mean, even if they don't kill your whole HD, they might just casually overwrite a few files or something...

BUt, if you want to continue to be reckless:

You guys are only modifying the data section. You can't touch the code. When it changed the path, it was changing something in the data section. If you want to do really kewl and stupid (as in dangerous) stuff, look up the header of PE executables, and set the flag to make the code section writeable. That way you really change what the program is doing. Whenever you got pointer errors (access violations), it was probably because the code was trying to write to it's own code section and couldn't. You might have wanted to code these in ASM also, much less bloat.

Or wait, you were changing the file on disk, not in memeory, weren't you? Ok, disregard all that

Following the idea of making a specialised enviroment, I have some questions for the masses:

• How low level should the opcodes be? Assembly-esque (direct register use and whatnot), or higher level (registers, stack, etc automated)?

• If assembly (or lower), how many registers, stack size, etc?

• How much memory would the enviroment have?

• Should its HD be a disk image, or could each progranism have its own file?

• If disk image, how big?

• If files, should they be restricted to a 'disk' folder, or be free to wander the (real) HD? (The second option would be more fun, methinks, but you'd need to log the location of all the files.) *

• Should a program be able to kill other processes, as well as delete their files?

• Should the processor handle memory leaks, or would the progranisms be forced to use their initiative and invade lost memory?

• The advantage of using an enviroment to track and run the progranisms is that you can still have them popping up unexpectedly on your desktop, but the enviroment can block attempts to overwrite or delete files not on its list (so your non-progranism files are safe).

I might have a shot at an enviroment, but I'll wait for our ideas to settle a bit. I don't want to write something noone wants.

For level: I say machine opcodes. Shared memory is likely a bad idea, though, if you want multi-tasking. Have the stack be as large as you feel is necessary. Registers? Depends on what you need. You're going to need things like an IP, an accumulator and data register, etc.

Right, so, progranisms shouldn't be allowed to mess with each other while they run, right? Just with each other's files?

In that case, is there any point in multitasking, or would just running progranisms sequentially off a buffer do just as well? That is, taking the progranism from the top of the buffer, running it, and adding any new progranisms to the bottom of the buffer.

Actually, that would remove the point of having delays. OK, I just answered my own question. But would multitasking still be worth it if they can't mess with each other?

If you wanted to reduce the havoc they could wreak on each other, but still allow some sabotage, you could kill any access violating progranism, but leave the change changed.

[edit]
My thoughts on memory sizes:

65536 byte RAM (2 byte memory bus)
256 byte stack (1 byte stack pointer)

Registers:

Accumulator (1(?) byte)
X + Y reg's (1(?) byte each)
instruction pointer (2 bytes)
flags (As big as necessary. 2 bytes is pro'lly max.)
stack pointer

The memory address register, memory data register, instruction register and so on can be automated if it's working at Assembly level, but if it's right down at machine code then they'd be needed as well.

As I recall correctly, stacks are low level, not high level. Built directly into the processor. Anywho, I feel that all of us should make our own VM Why do I feel this? Because it's good practice, I mean, who doesn't want to make their own VM It helps you to understand how computers work, which is a requirement when you get into deep engine design. So yea, we'll all make our own VM, find out which one is best, and if we can't decide which is best, we'll squeeze 'em together into a mega VM

Here's my idea for a processor design:
*7 32-bit registers: A, B, C, D, E, F, G
*2 32-bit memory pointers: H, I
*8000 bytes of stack

Why so many registers? When I did my first custom VM(processor emulator) I did that whole Xh, Xl, thing, which basically gives you extra registers without the CPU having to store more registers....well that idea blows, this is a VM and the number of registers doesn't matter in a VM, so I went all out and put 7 32-bit registers >8)

Why so much stack? cause...I like stack.

Operations include: MOV, ADD, SUB, MUL, DIV, AND, OR(EOR), XOR, BSL(<<), BSR(>>), LJP(local jump), GJP(global jump), INC, DEC, MMV(Memory Move), IF operations, PUSH, POP, INT

I think that's it.... The whole local/global jump idea is this: local jump will jump in reference to the program's memory, global jump will jump in reference to the WHOLE memory. Now, I haven't given direct support for function calls, because I believe I shouldn't, I'll give support for it in the Assembler which will convert it to the pure machine version(PUSH registers, LJP), this'll give progranisms more control...although maybe I don't want them to have that much controll...hmm...maybe I'll give support for it...ya. The VM will be multitasking, no access violations to allow for hacking. I think that's about it, so far I've written up the MOV portion of the OPCode document, I'm dumb!, all those registers take a long time write(81 different combinations, excluding a constant...which would make it 90).

No, the stack is in ram, and the cpu has a pointer to its current position(ESP).

Still, the point stands, the feature is built into the processor, your program doesn't have to handle pushing, poping, and keeping an ESP pointer.

But yea, I thought it was in the CPU...guess it wouldn't make too much sense in the CPU....anywho, thanks for pointing that out.

Um, I was wondering, does anyone know of any good tutorials on VM Development? I've googled like mad and I get all sorts of JavaVM crap, that doesn't really help...

Obviously you could find processors with built-in stack(like 256 bytes), in simple electronic devices. But not in PC.

Carrus85, there isn't much too it. Just build your interpreter and then add stuff like multitasking to it. If you really want some help though, search for info on emulating things like the nintendo, that'll help with writing the interpreter.

Besides, what the heck is the point of having the stack in the processor? Just write a class that encapsulates the stack, or just use the STL class, and BINGO! Stacks Made Easy...

BTW... PLEASE Someone tell me where a tutorial on designing VMs is located.

EDIT
--------------
William Hmm... That is what I thought.

Personally, I was thinking about customizing the VM commands so they are designed around the our "evolution" concept. True, it would be quite high level, but that isn't an issue.

I just need to figure out how to implement logic of some form.

Speed.

True, but with todays processors, stacks in the processor or stacks in the CPU don't make a lot of difference. I mean, the TI89 has a processor stack, but that only helps to a certain extent.

yea, RAM is fast, but seeing as how it's getting faster, it isn't fast enough . But personally I'd rather have faster CPUs than a big stack sitting in the CPU, plus the stack in a CPU wouldn't be used because for Windows and other OSs to operate in a multitasking environment, they must change the stack from program to program...the RAM system works great cause all you have to do is swap out the ESP.

And the difference between processor and CPU is?
AFAIK it the same thing. Or is there something i don't know about?

Heatley: That's why you don't see CPU stacks on normal x86 CPU's, but more usually in embedded systems.

yea, I figured that out...re-organized my logic and junk.

Umm, CPU is a dangerous word. Originally I think it meant processor(Centeral Processing Unit), but now adays it can also be used to describe the computer as a whole...anywho, I was just using it as a synonym for processor.

Well, nowadays, people call the monitor the computer, and the case the CPu

That's probably cause of the Mac and how some of their comps are just a monitor with a computer crammed into the base of the monitor...anywho, I'm on OPCode 01BC after documenting MOV, ADD, SUB, MUL, DIV, AND, and EOR...my hand hurts.

Is this the longest thread in GD&C ever?

I have an old idea of making a life simulation where I would let bugs (beetles) evolve and mutate. They would contain a set of genes, one determinig the sex (xx and xy) and lots of others determining outlook, behaviour, fertility etc. Compared to your mutating progranisms this might not be as exciting, but it wouldn't harm my computer.

A good prologue or trailer for Terminator 4: "Back in the early 21st century, some geeks on an Internet site discussed what would happen, if a computer program were given a possibility to mutate. Little did they know what their..." Feel free to continue.

Johan,

I actually saw someone who made a program that simulated evolution and breeding for beetles shapes over 15 years ago on the spectrum. Pretty impressive for the time.

Is 'copying and changing randomly some bytes' really ai? I would say no.

In fact, true ai can never really exist into a machine. Machines always need instructions from a user(input) so the machine will always act based uppon its given knowledge.

An evolutionary type of program would be for instance:

- a program that continiously scan's its own source.
- a program that only starts by copying itself, but also tries out other abilities
- a program that 'learns' how to code another function to clear up 'the mess' (breeded programs that are not needed anymore)
- etc...

the problem remains-> programs will never learn this if they don't know they CAN learn this.

I have been working almost 3 years on a Counter-Strike BOT AI. And some dude just came in smashing the entire Bot concept idea because all counter-strike bots are NOT REAL ai. They are purely 100% given instructions, acting they way they do because the programmer tells them to act like this. Even when using statistics and arrays with low/high scores using trial/error systems and such, it is still hard coded. Because-> the bot never will try another aproaches but the given one by the user.

I have made a little, 'ai document', here it is:

AI is nothing but 'problem solving' as for every human actually. A simple example would be 'pick up a glass'. For us, we see the glass, reach, grab, take it and perhaps drink. For an AI its different, whats a glass? (AI needs user input, it is not able to 'learn' that itself), how to reach? do i have instruments for that? (arms? hand? , etc) when reached, what to do? grab? whats that? etc...

if the user will insert the commands for the computer:

function: grab()
{
use arm to reach, if not reachable, use legs to move closer
grab object with hand
move arm back and hold object in front of body
}

... AI is a tough thing, gets ya dizzy (certainly at this time. :S)

I disagree. I know we don't have the knowledge to create a real AI, but there is also so much we don't know about this whole idea. We don't even fully understand how our brains work.
I believe mankind will create a real AI in the future.
And i don't think that there will be any problems with robots walking around and killing all of us.
If we can make a machine to think, we can also force it to test its actions to some rules. Like the robot laws by Asimov. Or some better ones if needed.

Umm... perhaps you should substitute "AI" with just plain "I"? What we have is exactly that: artifical intelligence. This is a simulated behavior, however gotten. If you think we can't truly teach computers to learn, then you are right, but only because you're being stubborn. Be a creationist: God put humans on this Earth, already we had the knowledge to learn and breed and change. Why not the same for computer programs?

Acording to my crazy logical theories:

There are currently two levels of learning known. The first is what I call brute force learning. This is what the Progranisms mimic. They try random approaches to "life" finding the best ones. This is just like when you hack a password "brute force" you try EVERY combination until one works. Now, this is not what you would call intelegent, but it is learning.

The second level is what we call intelegence. This is where, instead of randomly trying things, the entity trying to learn with use past experiences to influcence the "randomness". It is still random in a sense, but it reorginizes what random ideas it picks first.

I'm not sure whether the second level is possible or not in machines, since machines, like was basically said, are static, they follow only instructions, the instructions may change, but they are still restricted.

There is a way to find out if it is possible though, and I think it is through the first level. Maybe the Progranisms can evolve to the second level? I'm not sure. I have way too many theological questions that need answers before I can decide if this is truely possible. It seems logical, I mean we are all made of the first level of learning anyway(cells), so it would make sense that it would be possible, but we are still limited in knowledge, we don't know all that goes into "life" and thinking...so...whatever.

Let's leave it at that, PLEASE, cause this is a flame war waiting to go off, so let's be civil, please.

Oh, and Johan, your idea is known as Genetic Algorithims I think...not sure, but I think.

BTW, [url http://alifegames.sourceforge.net/] Check that out! Cool stuff, genetic algorithims. The first game kinda blows, cause it is poorly designed you can't turn(eeeee), but it's a nice idea.

I have to agree with William on this one. Intelligence in life, according to Darwins theory of evolotion, was not just initialialy intelligent... In essence, early lifeforms WERE following just a predefined pattern. Find Food, Consume, Divide, and Repeat. This, in essence, is what William is refering to as "Brute Force" Intelligence. Personally, I prefer to call it "Psuedo-Intelligence," just so I can use the word "Psuedo" . But anyway. Following this pattern, however, the programisms, in theory, will evolve out of this cycle, just because of the "survival of the fittest" theory.

When the programisms start "learning" to avoid hazards... Such as a virus scanner, process killer implemented by the VM, or another programism... Then they start developing rudementary intellegence.

True, the chances of developing human-level intelligence are slim to none to nonexistant, but it is still an idea.

Just think of all the processing power it would take to generate such an AI via programisms...

Gets the urge to go theological crazy "No William, you can't start the war" "Fine... But if we start a war just think how big this thread will get then >8)" "No, wars are bad." " "

Ok, I've consulted myself and have decided to not go "Theological Crazy".