Not long after I started undergrad at UofT, before the days of the world-wide-web, a program I had written in high-school was mentioned in a newsletter I found on the Internet. I've been slowly moving old references, such as this, out of ref_ (and friends) and into a more flexible archive here. I still think the article is cute and the program Net is a source of a lot of nostalgia. Here is the excerpt from the article:

Pardon Me, But Your Teeth Are In My Neck by Chris Lindensmith

In some of the past tournaments, one very effective type of program has used vampiric capture to defeat opponents. Cowboy won in 1988 with a fairly straight-forward vampire that used the captured cycles to try to bomb the remaining uncaptured cycles. In 1991 another vampiric capture program, Vlad, took third place. The generally good performance of vampires has prompted proposed variations on the standard such as the descendent count limit suggested by Jon Newman, but there do not seem to be many (if any) programs that are actually designed to counter-attack vampires. I will discuss here some of my attempts to make so called vampire killer programs along with their advantages and drawbacks .

Vampires work in general by preparing a section of code that I will call the "trap" and then attempt to hit their victims with a JMP trap bomb. Once a process has been captured, the victim process usually runs in a loop in which each time through the loop each captured process executes a SPL trap instruction in order to slow down the opponent. The trap usually contains a counter that tallies the number of captured processes until the maximum number of sibling processes has been reached, all of which then commit suicide leaving the vampire victorious. Some programs also subvert the capture processes and use them to throw DAT bombs at their own siblings.

It is obvious from looking at how the vampire captures its prey that it must provide some sort of pointer to its own location. This is what we will use to track and destroy the vampire, although there are limits and clever programmers can write vampires that are more difficult to track and kill.

Since the vampire is spreading information all through memory as to how an unsuspecting program can find its trap, a vampire-killer simply needs a way to find these bombs and take advantage of the information that they contain before the bombs find the executing part of the program. Perhaps the simplest, although not the most effective means is to look through memory one location at a time and bomb the location to which any non-zero memory location points.

This will not work if the bombs start coming from above instead of below, so you could easily extend this idea to check a few prepared "pickets", one above and one below, in each of which the contents are known, and then bomb the vampire when it alters one of the pickets. I tried a program like this for my first vampire- killer when all I had were the 1988 tournament programs to compete against. It clobbered Cowboy nearly every time. As long as the vampiric bombs did not begin closer to the program than to the picket, Cowboy was easily beaten, as are most of the vampires that appear in the tournament rosters.

Authors of vampiric programs can also try techniques to avoid being so easily killed by anti- vampire programs. One simple idea is to insert one or more levels of indirection into the jump instructions that lead to the trap, placing intermediate locations safely away from the executing processes and the trap.

For low order indirection, where there are only a few intermediate locations, an indirect-vampire killer is easy to write; just insert a few ADD @targ, targ instructions. Since most traps are small and the executing instructions usually refer only to locations within the trap, this will still leave targ pointing somewhere within the trap and will also reduce the effectiveness of indirect vampires.

There are a few catches though. Since many traps include bombing instructions, you could end up pointing to the next location that the captured cycles are intending to bomb. This is not much of a problem if the trap has not been used yet and the bombs are set to begin nearby, but if the target pointer has been running, the indirect- vampire-killer could miss entirely. Adding a large number of ADD instructions could also make your program a larger target and slow it down so that the JMP bombs can get ro it before it finishes off the vampire.

For higher order indirection, such as a long trail of JMP bombs that reference each other all the way back to the trap, the problem is more difficult but the vampire killer can expect to obliterate at least a part of the trail back and avoid capture. This still leaves the "captured" process jumping into oblivion, so it might be wise to split off a new process at a location away from the impending JMP oblivion.

Another simple technique is to separate the trap and the bomber section of the vampire by a large number of DAT statements at load time. A vampire killer would still be able to destroy the trap successfully preventing capture, although it would not get a quick and easy win.

Perhaps the most effective trick is used by the vampire program Net. It looks quickly through memory and only throws bombs when it finds a potential victim. This stealth can be devastating to nearly any program, and so far I have not been able to write a program that can consistently find it before being found. ¹

So far, all of this discussion has assumed that opponents will use an offense of vampiric capture exclusively, but this is not at all true and leads to one of the major drawbacks of vampire-killing programs speed (or lack thereof).

The vampire-killing programs are primarily defensive and need to have sibling processes that go through memory and attempt to kill off any other types of program that may be present. This leaves the vampire-killer running at half- speed or even slower against programs that do not try to capture their enemies.

It also greatly increases the size of the program, with perhaps a segment for offense, a segment to build and check pickets, and a segment to do the bombing when a vampire is found. The lack of speed and the large size can be serious disadvantages in tournaments where many small, fast bombers appear which quickly bomb memory and cripple or kill the vampire-killer. There is some comfort in that large programs can often survive corruption and be deadly even in some new, unexpected form.

In running one of my recent programs against the l990 tournament roster, it performed better that everything except XTC, Net, and three or four fast bombers like ZD. Hopefully some of the speed problems can be overcome and vampire killers can vie for the top spots in future tournaments.

There is something uncanny about this trip down memory lane. I remember enjoying a moment of "vicarious" pride at Net's mention and babbling about Quantum Mechanics (eg. in my QM class) and wondering how I should go about making a "Quantum" version of Corewar for a living. More than ten years later I've put up an Internet server-- Science.Fiction.Org-- running my Quantum Coreworld. And in the coming days, weeks (and months) I'll post more about it here.

I have to confess that all this is, somehow, terrifying. When you get a shot at child-hood dreams as an adult it's only your own fault if you mess up.

1. Lindensmith, C. 1992. Pardon Me, But Your Teeth Are In My Neck. The Core War Newsletter 5(4):5-8. GZIPed Postscript.