Xref: utzoo comp.binaries.ibm.pc:124 comp.sys.ibm.pc:9659
Path: utzoo!utgpu!water!watmath!clyde!burl!codas!mtune!whuts!picuxa!tgr
From: tgr@picuxa.UUCP (Dr. Emilio Lizardo)
Newsgroups: comp.binaries.ibm.pc,comp.sys.ibm.pc
Subject: Re: PC Aquarium program
Summary: it's not a write
Message-ID: <418@picuxa.UUCP>
Date: 17 Dec 87 15:30:06 GMT
References: <1070@sjuvax.UUCP> <19637@amdahl.amdahl.com> <850@neoucom.UUCP>
Organization: Trenton Home for the Criminally Insane
Lines: 27

In article <850@neoucom.UUCP>, wtm@neoucom.UUCP (Bill Mayhew) writes:
-> 
-> <<<Aquarium tries to write to disk upon exit>>
-> 
-> Are you sure?  I'll bet that it is rloading the overlay portion of
-> COMMAND.COM when it exits.  If you run a big program that uses all
-> available memory, COMMAND.COM unloads itself.  Note that eventhough
-> you always are allocated the entire free memory pool when you run a
-> program, COMMAND.COM only reloads when the memory it is residing in
-> was actually used.
-> 
-> Here's a way to test.  Boot from a floppy.  Run aquarium from a
-> different floppy that does not have COMMAND.COM on it.  When
-> aquarium exits, see if the system prompts "INSERT DISK WITH
-> COMMAND.COM".
-> 
-> Naturally, one possibility is that the aquarium *is* a trojan.
-> The only way to be sure is to whip out DEBUG and pick it apart.

I ran aquarium from a write-protected floppy, and it did not give me any
access errors.  Can this be considered an adequate test?

-- 
Tom Gillespie  ( ...ihnp4!picuxa!tgr) | (attmail!tgillespie) (201) 952-1178
AT&T/EDS Product Integration Center  299 Jefferson Rd. Parsippany NJ 07054

"Don't take life so serious ... it ain't nohow permanent."  -- Walt Kelly