"Immanuel Kant was a real piss-ant who was very rarely stable.
Heideggar, Heideggar was a boozy beggar who could
think you under the table.
David Hume could out-consume Schopenhauer and Hegel.
And Whittgenstein was a beery swine who was just as
sloshed as Schlegel.
There's nothing Nieizsche couldn't teach 'ya 'bout
the raising of the wrist.
Socrates, himself, was permanently pissed.
John Stewart Mill, of his own free will,
after half a pint of shanty was particularly ill.
Plato, they say, could stick it away, 'alf a crate
of whiskey every day!
Aristotle, Aristotle was a bugger for the bottle,
And Hobbes was fond of his Dram.
And Rene Descartes was a drunken fart:
"I drink, therefore I am."
Yes, Socrates himself is particularly missed;
A lovely little thinker, but a bugger when he's pissed."
The philosopher's song, Monty Python
SVP: A MASS OF UNREADABLE CODE AND COMPLEX PROGRAMMING?
by Chris Brookes
Well that's debateable. It has been asked of me, or should I say
suggested to me - by Richard, to write this article on how it
came about, the principles involved, and generally give a little
back-ground data to it. Certainly. Here is the low down on how it
came about, which inevitably leads to the principle it uses.
Sorry, did I sound a bit reluctant there?!
It all started a few months ago whilst I was in the middle of
writing a completely different program. I can't quite remember
which, but that's not really important. Anyhow, I was just at the
compile-link-run stage when all of a sudden the mouse x
coordinate flipped... after a few moments of playing with it (I'm
still talking about the mouse you know...) I switched off, and
booted up my virus killer. After 5 minutes of cleaning the
important disks (it was here that I made my mistake), I then
loaded up a certain program by IKI of TSB so that I could install
some custom boot-sectors. One of them happened to be BOULBOOT 3,
and don't ask my why, but I happened to like this one. So on my
disks it went.
After getting back to my program writing, and after about 2
hours/1 meal/3 cups of coffee, the Ghost virus reared its ugly
head again. It appeared that I hadn't cleansed all of my disks.
So, I put my virus killer disk into the drive and hit the soft
spongy thing at the back of my ST. Up popped the BOULBOOT anti
virus, but instead of telling me it had installed, it zapped the
screen with a funny colour lasting for a lengthy pause. It then
told me that it thought it had erased a virus. Well I knew it
had, but instead of loading up my virus killer and sorting the
virus out, I wanted to see the colours again. Don't laugh... they
were quite good, sort of diagonal lines across the screen, and in
over-scan mode. Very impressive in a boot sector, never mind an
Imagine my disappointment when they didn't come on again after
hitting reset. Well, no matter how I tried, how many times I
pressed reset, it would not display those colours again... and so
there I sat wondering what was going on. After a few minutes I
came up with a tried and trusted method. Try to regenerate my
steps exactly. I did... it worked... but it wasn't good enough. I
wanted to know exactly what was going on. It was at this point
that I had my first vision of SVP, because I had worked out the
steps involved. Firstly, infect the ST with the virus, and then
secondly, run the BOULBOOT boot-sector. After doing this, the
Ghost virus was fooled into thinking it was already installed.
My program was going to do everything the others did, all the
steps in one go, and it was going to do it in GFA Basic. The
first problem, and perhaps the most difficult, was trying to work
out what EXACTLY the Anti-virus did to your memory, and to the
resident virus. On that particular night, it was getting late,
and writing a routine to just take coordinates from the mouse was
getting difficult, so I called it a night. I had toyed with many
ideas for the Anti-virus 'Emulation' in GFA... such as storing
the Anti-virus with INLINE, then writing it to the boot sector,
then running the boot sector, then erasing it... but in typical
programmer fashion... I was taking a sledgehammer to crack a nut.
I was going round the houses... beating round the bush... totally
avoiding working out what the Anti-virus actually DID. So, as I
just said, I called it a night and went to bed.
The next day, I started on it with a fresh mind and this helped
enormously. I finally figured out that the Ghost Virus must be
altering some system vectors, and thus enabling the Anti-virus to
recognise the altered vectors and do something about them. So I
set up a watch on vectors that I new were likely to be changed by
the virus. These were basically, HDV_BPB, a few other HDV_'s, and
the reset vector. After a few minutes of trial and error it
turned out to be the HDV_BPB (if I remember rightly) and the
Reset vector that were being modified. After that, it didn't take
long to realize that all BOULBOOT was doing was to reinstate the
proper values to a modified vector. So, I had overcome half of
the hurdle already. If the Ghost Virus was installed in memory, I
could change the vectors it modified back to how what they were
supposed to be with no problems, and so eliminating BOULBOOT
The next major step involved in the production of SVP was that
of installing the virus into memory myself from GFA. Well...
first I had to work out where exactly it installed itself into
memory. This was easier than you might think, because I just took
a guess based on where the modified system vector's pointed to.
With my address that I had guessed, I then wrote a small program
to copy the area of memory around that value into a file on disk.
The program took about 512 bytes either side of the address.
After writing this program, I first ran it without the virus
installed, and then with the virus installed. Again, by this time
of the day it was late and I had been on my ST for about 8
hours...so naturally I had a serious headache developing.
The next time I continued 'Developing' SVP was some 2 days
later, due to not having much spare time. I then had to use a
program simply called COMPARE, which, believe it or not, compares
two files. It then tells you which bytes are the same etc. In
doing this, I discovered that there was a block of 473 bytes that
were identical. This was the virus. From this I was able to
calculate, without much work, where the virus installed into
memory. I then repeated the memory copying to disk again, so that
I had only had the 473 byte block of code on disk. So now, I had
almost overcome the major hurdles.
Now I am a perfectionist by heart, and the thought of having an
extra file for the virus data didn't appeal to me at all, firstly
because it would mean having an accessible virus on the disk, but
mainly because I wanted 1 little neat file that nobody could play
with. To remedy this, I wrote yet another program to whizz
through the virus file adding the appropriate DATA $ statements
to every byte, and then saving it back. After doing this, I just
merged the data into GFA basic, and that was that problem solved.
It was at this point that I realized I had virtually made a form
of Trojan virus with this program...so after quickly ridding my
mind of such nasty thoughts, I carried on. After all of that, I
finally tidied up the program somewhat, and did my first test
run... the program INSTALLED THE VIRUS, POKED THE SYSTEM VECTORS
with the viruses address, and then CHANGED THE SYSTEM VECTORS to
what they should be. It worked! Now call me daft, but it was here
that I realized that there is absolutely no point in POKING THE
SYSTEM vectors, only to RE_POKE them to their original values
straight after! That MAJOR HURDLE I had overcome a few days ago
(BOULBOOT) now just faded away into insignificance.
By that time in it's development stage I had a firm idea of the
principle behind SVP. I new exactly what the virus did. On
booting with an infected disk, it checked to see if it was
already present by looking for a specific byte, at a specific
address. The question was... which byte and at what address? Now
after a LARGE amount of time trying to find this out, I did
eventually discover it. And so it turns out that in only 1 line
of code, you can protect your ST from the Ghost Virus. I no-
longer needed to install the full 473 bytes... just the one!
All my work over the past 3-4 days all accumulated into 1 line
of code! 1 line!
What I had to do next was to make it into a useable piece of
software. I made it pretty versatile, in that it could be run
from an auto folder (more later) and give options by text, and
also so that it could be run from GEM and make full use of, un-
suprisingly, GEM. Just for sheer useability, I made it so that it
could boot as an accessory also.
And that's it! I suspect I'll see a 101 clones of this in the
near future now I've spilled the beans, or so to speak, but who
cares... I stumbled on the idea and made the program first!
Oh yes, almost forgot. How do you recognise an auto folder
booted program from GFA? Well, it's quite easy really, just do
CLS, then PLOT(1,1) and then check with POINT to see if the pixel
is there...if it is, then GEM is installed, otherwise you're in
an AUTO folder. (sneaky, I know!!)
If anyone wants to write to me for any reason, then please do
so. I'll be happy to exchange software etc., or possibly write
the odd custom program for somebody. See my address in the doc
file to SVP.
The program and document files may be found in the folder
"S_PROTEC" in the "PROGRAMS" folder on this disk of ST NEWS.
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.