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]