To:  Ken Loomis, FART Chairthingy
 
Dear Mr. Loomis:
 
I read your statement with interest.  I too am concerned about the Virtual
Ferret program.  I have had a chance to examine the "FERRET" executable, and
humbly direct my findings to you.  I have discovered many previously
undocumented features of the program, as well as a number of serious
run-time errors.  Allow me to share my experiences.
 
As far as I can tell, FERRET.EXE takes input data from files in the
directory C:\FERRET\KIBBLE, one byte at a time.  This data is processed, and
the end product is in dumped to C:\FERRET\BIN...or so it would be, if
FERRET.EXE was working properly.  There is a terrible error.  Output files
are instead dumped all over the hard drive.
 
As soon as I saw that this was happening on my system, of course, I hit
<CTRL>-P to stop it.  A second, even more horrible realization hit me:
 
The process FERRET.EXE traps and ignores all control signals.  Simply,
FERRET.EXE does not recogize the <CTRL> key.
 
Of course, my system would not respond to a soft boot (<CTRL>-<ALT>-<DEL>),
and I was forced to hard boot it.  The random dumping stopped temporarily.
 
Later, I found that if you hit <ALT>-<PETS>-<FERRETS>, a handy help menu
pops up.  A hard boot is unneccessary, and in fact, not recommended.  Why
isn't this documented??!!!
 
I asked the advice of a technician re: the dumping problem.  I was told
that FERRET.EXE will continue to randomly dump output on the hard drive
unless I get a memory upgrade and get the latest patch, which allows
FERRET.EXE to run any output process with the .LEG extension.  (Something
about short legs and even shorter memories, anyhow.) He, in turn, referred
me to a Very Expensive Technician, or VET, whom he said could talk me
through the upgrade.
 
However, upon calling the VET I discovered that FERRET is not
user-servicable, and I would have to bring the whole system into the shop.
The VET, in severe tones, warned me that I would void my warranty if I
elected to open up the system myself.
 
While I had the VET on the phone, I asked him about another problem that had
cropped up on my system since the installation of FERRET.EXE: the hard drive
occasionally begins to thrash wildly.  The VET told me that this was normal,
and due to the WARDANCE ROUTINE.  This applet cannot be uninstalled.  He
suggested turning "turbo" off.  The VET also stated that applying a light
lubricant--something called "Ferretone"--to my system input device may
temporarily cause the system to cease thrashing.  The system quiets for the
brief period of time it that takes FERRET.EXE to read in all the input off
the device.
 
I decided to let the VET have a look at my system.  To my dismay, the VET
discovered that FERRET.EXE had munched up many of my files, and fragments of
these files had been spread all over my hard drive.  He even found pieces of
my files in C:\FERRET\BIN.  The VET told me that I must remove all files
with the following extensions:
 
        *.RUB   (RUBBER file type)
        *.COR   (CORK file type)
        *.ERA   (ERASER file type)
        *.SBL   (SUPERBALL file type)
 
The VET warned me that fragments of these files could get stuck in the
system I/O ports, necessitating expensive repair.  When he found I also
downloaded UNIX files to my system, he warned me to check my LaTex documents
regularly for signs of wear or damage, and to delete them when it looked
like FERRET.EXE had affected them.
 
He also told me that the newest port of FERRET.EXE (a port to Windows 95)
actually shared a run-time error with the older, Mac version: FERRET.EXE
will remove items from both 95's Recycle Bin, and the Mac's Trashcan, and
scatter the files all over the desktop.  Users of both operating systems
must ensure that they regularly delete unwanted files when running
FERRET.EXE.
 
Win 3.1 users using WinSock to connect to their net provider will notice
that the WinSock icon will disappear under other windows on the desktop with
fair regularity.  Users are advised to check under other apps before
assuming that WinSock is no longer on the system.
 
I asked the VET why there had not been a port to BSD (Berkeley UNIX).  The
VET's eyes went wide, and he leaned forward to tell me the dreaded truth.
Berkeley, he remined me, is in California.  His eyes narrowed.  He told me
that BSD was able to detect when a process was trying to alter data outside
of the process' allocated memory area.  BSD KILLS the FERRET process when
FERRET.EXE tries, simply, to be itself.  "Core dump, lights out!" declared
the VET, drawing a finger across his throat.  I shuddered.
 
I conceded that FERRET.EXE might be quite usable if the bugs were worked
out.  The VET agreed, and reminded me that any utility used to remove the
bugs must have been tested with KITTEN.EXE, to preserve program integrity.
Debuggers used in the development of CAT.EXE and DOG.EXE are not
appropriate.
 
Thank you, Mr.  Loomis, for your time.  Allow me to conclude that it should
be FART's goal to lobby for the development of a stable FERRET executable.
 
Sincerely,
 
Lynn, Department of Confusing Misinformation Science, University of Guelph.
[Posted in FML issue 1469]
[Posted in FML issue 1469]