Operating system? That's nothing.

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

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

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?

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.

shrugs

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...

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

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...

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

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.

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.

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...

<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?