Make your own free website on Tripod.com

Lesson 7. Testing.

Prev || Home || Next

bar.gif (11170 bytes)

In testing a virus on your own system, you subject it to many continuous attacks - maybe even ones that are unintended. There are some rules to follow to be sure that you can keep track of it's location and make sure it doesn't destroy your work in the process.

1. SysBeep debugging. I'm sure most of us a pretty familiar with this technique. It's compatible on all systems, and it's an aural identification. No visuals to set up, no extra resources. Simple SysBeep(0); is sometimes enough to know that everything's all right. When testing your duplication code to find out when it actually happens, use SysBeep after each one and then check to see where it went.
2. Modification dates and times. If you use random selection of files to infect, it becomes rather difficult to find which one got infected. If you know when an infection happened, you can immediately check the modification dates of all files - simply by using the Find command in System 7's Finder.
3. Text Files. This could be known as a common-file technique. For testing purposes, use a mechanism that whenever an infection takes place, the virus writes the process and the file names and such into a common file in a common folder somewhere. This way, you can check the text file afterwards and know exactly what your code has done. You need not make the mechanism too elaborate, as it will only be for use in testing.
4. Backup, Backup, Backup. The thought police are at it again. In these cases, it's all too familiar. A trashed project is no fun.

bar.gif (11170 bytes)

Prev || Home || Next